Skip to end of metadata
Go to start of metadata

The page is intended to summarize all the requirements for Casablanca Release. These requirements will need to be prioritized to realistically fit within the Casablanca Release Timeline.

This is not yet the Casablanca Release scope. Release Scope will be finalized by M1 Release Planning.

Projects intended to participate within Casablanca release are posted in wiki.

New projects proposal are posted here. These projects need to be reviewed and approved by TSC.

Some of the Use Cases, Functional and non functional requirements are carried over from previous Amsterdam and Beijing Releases as they required multiple releases to be implemented.

The Requirements extracted from SP lists of priorities for Casablanca are covered either by the Use Case, the functional requirements, the non functional requirement or within a project scope of work.


Use Cases 

Use CaseOwner

Projects or functional requirements Impacted

for Casablanca

Link(s) to High Level Design (HLD) /Low Level Design (LLD) (if any)Dependency (from/to) another project(s)T-Shirt Size (XS, S, M, L, XL)*Project's Impact: Test Only (TO), Code (C)Committed (C)/Partially Committed (P) or not (N) per Impacted projectsIf Partially or not Committed, then what are the gaps per impacted project (people/FTEs; HLD/LLD; etc)Company EngagementNotesM4 Status
vFWAT&THPA


All: Test OnlyN/A - part of regression testsN/A - part of regression tests


vDNSAT&THPA


All: Test OnlyN/A - part of regression testsN/A - part of regression tests


VoLTE

China Mobile

HPA


All: Test OnlyN/A - part of regression testsN/A - part of regression tests


vCPEKang XiHPA


All: Test OnlyN/A - part of regression testsN/A - part of regression tests


CCVPN

SO,OOF,  SDNC,UUI, integration

Stretch goal:

SDC, DCAE, external API.

NOTE: No project should be code impacted by this use case.

Materials Lin Meng. Material Jianguo Zeng

All; Test

Code:

SO,OOF,  SDNC,UUI

Stretch goal:

SDC, DCAE, external API,  CCSDK, HOLMES, POLICY

SO:committed,

OOF:committed (Huawei resources as required).

UUI:committed

Integration: committed

SDNC: (Huawei resources as required).

Stretch goal:

DCAE :  Not committed(Huawei &CMCC plan to contribute)

SDC: Not committed

External API:(VDF & huawei plan to contribute)

CCSDK: (Huawei resources as required).

HOLMES: (Huawei & ZTE to contribute)

POLICY: (Huawei & CMCC to contribute)

if projects not committed is just in strech goal, then we will dev based on exist features, may impact some usibiligy, but won't impact the final result.

DCAE : From discussion with Xin Miao (Huawei), this usecase requires new RESTCONF collector to be added into DCAE.This cannot be committed for R3 due to pending requirement clarification and architectural alignment besides resourcing constraint.

China Mobile, Vodafone, Huawei, ZTE

Contingent that Use Case owner are able to add resources on impacted projects and Integration agreement.

Refer to this link for CCVPN closed loop related support in R3.

ON TRACK

POC Demo planned for ONS at Amsterdam

OSAM/PNF

SO, Portal, External API, APPC, DCAE

HPA

**NOTE: OSAM uses the PNF capability similar to 5G use case. No new development efforts were identified to support OSAM using PNF

VNFRQTS (include PNFs)

OSAM Material

All: Test Only

ATT, Turk Telecom, SwisscomContingent that Use Case owner are able to add resources on impacted projects and Integration agreement

POSTPONED

Not M4 Gating

No Component development required for this usecase in Casablanca

Integration testing delayed due to resource contraint.

Defer to Dublin

(star) T-Shirt Size: Ballpark estimation for assessing the development/testing activities performed by the project team; not the integration team

  • XS - <4 Man/Weeks;
  • S - ~6 Man/Weeks;
  • M - ~8 Man/Weeks;
  • L - ~12 Man/Weeks;
  • XL - > 12 Man/Weeks.


Functional Requirements 

Functional RequirementsOwner

Projects Impacted

for Casablanca

Link(s) to High Level Design (HLD) /Low Level Design (LLD) (if any)

Priority

(from SP perspective)

Dependency (from/to) another project(s)



T-Shirt Size (XS, S, M, L, XL)*Project's Impact: Test Only (TO), Code (C)Committed (C)/Partially Committed (P) or not (N) per Impacted projectsIf Partially or not Committed, then what are the gaps per impacted project (people/FTEs; HLD/LLD; etc)Company EngagementNotesM4 Status
HPA

VNFSDK (minor)
SDC (minor)
Policy
OOF (minor)
SO (minor)
AAI,
Multi-Cloud
VNFRQTS

HPA Enhancements (For Casablanca Release)

Orange: 2

ATT: 2

China Telecom: 2

China Mobile: 1

Verizon: 2

Vodafone: 2

VNFSDK: none

SDC: VNFSDK, VNFD model

Policy: SDC

OOF: SO, Policy, AAI

AAI: Multi-CLoud


VNFSDK: M
SDC:XS
Policy: M
OOF: S
SO: S
AAi: S/M
Multi-Cloud: M 

VNFSDK (C)
SDC (TO/C)
Policy (C)
OOF (C)
SO (C/TO)
AAI (C)
Multi-Cloud (C)


Policy: Committed based on Intel providing resources

OOF: Committed

VNFSDK: Committed

SDC: committed based on Intel contribution.

SO: committed

AAI: committed based on Intel resources.

Multi-Cloud: committed



Intel
China Mobile
AT&T
VMware
ARM


ON TRACK

All code has been or will be submitted

ON TRACK

Unresolved dependency on SDC - two bug fixes required.

Update: Oct 18: the bugs on SDC have been addressed

Change Management -
Flexible designer/orchestrator

SDC, SO, VID

Link to Slide

Orange: 1

ATT: 1

China Telecom: 2

China Mobile: 2

Verizon: 1

Vodafone: 2

VID: on SO

SDC: on SO

SDC:XL

VID: M

Code: SO,VID,SDC

VID: Not committed (Note: VID part is "nice to have" - no dependency on VID from other projects)

SDC: committed based on Amdocs contribution

SO : Committed (with support from ATT resources)


VID: requires additional resources


AT&T, Amdocs


M4 READY

Details

M4 READY

Details

Change Management - traffic migrationSDNC, APPC, VNFSDKLink to Slide

Orange: 1

ATT: 1

China Telecom: 2

China Mobile: 2

Verizon: 1

Vodafone: 2


Code: SDNC, APPC

SDN-C: committed

APPC: Not committed

Orange: Committed

APPC: Not enough details on requirements, plus limited resourcesAT&T, Orange, Intel

M4 READY

Details

M4 READY

Details

Change Management - 5G PNF software upgradeSO, A&AI, Ansible/EC - test only support; SDNC/CCSDK- dev to incorporate 5G PNFsLink to Slide

Orange: 1

ATT: 1

China Telecom: 2

China Mobile: 2

Verizon: 1

Vodafone: 2



SDN-C: Committed
AT&T, China Mobile, Huawei

M4 READY

Details

M4 READY

Details

ON TRACK

Ansible playbooks have been submitted. SDN-C NB related LCMs started to support PNF operations

Change Management - CM scheduler

OOF, VID

VID - Nice to have - the functionality can still be delivered with OOF only (scheduler would need to be invoked through CLI)

Link to Slide

Orange: 1

ATT: 1

China Telecom: 2

China Mobile: 2

Verizon: 1

Vodafone: 2
VID on OOFVID: SCode: OOF, VID

OOF: Committed

VID: Not committed

(this can still be delivered with OOF)


VID: requires additional resources

AT&T

M4 READY

Details

M4 READY

Details

Scaling

Closed Loop Scaling

(High Priority)

Policy, CLAMP, SO, DCAE


Link to Slides   

Orange: 1

ATT: 1

China Telecom: 1

China Mobile: 1

Verizon: 3

Vodafone: 1

   

CLAMP: on Policy

Policy: on SO

CLAMP: M

Code: SO, CLAMP, Policy

Test: DCAE




CLAMP: Committed with risks (dependency on Policy)

Policy: Committed with risks (TBD)

SO: Committed

DCAE: Committed


AT&T

ON TRACK

All code has been or will be submitted

Scaling

Beijing Improvements

(High Priority)

 Scott BlandfordAPPC, SDNC, SO, AAI, VID

 VID: on SO

APPC: on SO

VID: XS

AAI: XS

Code: APPC, SDNC, SO, AAI

AAI: Committed

APPC: Committed

SDNC: Committed

SO: Committed

VID: Committed


 AT&T

ON TRACK

All code has been or will be submitted

(VID is having issues with test environment) 

Scaling

Controller_Topic_ID

(Medium Priority)

 Scott BlandfordSO

Code: SO

SO: Committed


 AT&T

ON TRACK

All code has been or will be submitted

Scaling

Homing and Capacity Check

(Low Priority)

 Scott BlandfordMulti-VIM, OOF, SDNC, SO OOF: on Multicloud and PolicyOOF: SCode: OOF, SO, SDNC, Multi-VIM OOF: Partially CommittedOOF: Resource issue if R2 solution needs to be extended for new policy constraints. AT&T

POSTPONEDPushed to Dublin

5G/PNF

Plug and Play

SDC, SO, SDN-C, A&AI, CDT, Modeling, VID, DCAE, DMaaP

Link to Slide

Orange: 2

ATT: 1

China Telecom: 3

China Mobile: 1

Verizon: 1

Vodafone: 2

VID: on SO



VID: S

AAI: XS? need clarification on what's expected

OOF: No impact


Code: VID

Test Only: SDC

Code : DCAE


VID: Committed based on Nokia's contribution

SDNC: committed

SO: Committed (with resources from Nokia)

SDC: support based on current sdc capabilities from Beijing.

APPC: No impact

AAI: No code change, only modeling changes

OOF: No impact

DCAE: committed

DMaaP: committed

APPC: Per review of slides, does not appear to be anything specific for APPC in Casablanca. Items mentioned are more longer term, roadmap items

AAI: Expecting this to be modelling/schema updates only but unclear. Need additional information and analysis by AAI SMEs

OOF: Additional information required on policies required for PNF placement


DCAE: Committed based on Nokia's contribution on PRH

AT&T, Nokia,

SUBMITTED

Code has been developed and submitted.

ON TRACK

SO Code Merge. Health Checks for PRH done in DCAE.

PENDING

E2E.Test cases need to be updated (for integration & testing) after1st run of whole flow. Sunny Day scenarios to be prepared (for testing).

5G/PNF

Software Version Reporting

 CCSDK, SDN-CLink to Slide



CCSDK: committed

SDN-C: committed


AT&T



ON TRACK

A&AI and SDC support has been developed.

POSTPONED

Usage in the 5G Software Upgrade Use Case is pushed to Dublin

5G/PNF

Lifecycle Management Support

(Restart, Suspend of PNF)

SDN-C/SDN-R. Controller support for operations. SDNC (SDNR) dev to incorporate 5G PNFsLink to Slide



OOF: Supports Change Management Scheduling

SDN-C: Committed

Will address this via Change ManagementAT&T, China Mobile, Huawei

INVESTIGATING

SDN-C Interfaces need investigation. Want to make sure SDN-C is supporting Ansible.

5G/performance Analysis and Optimization

High Volume and RT Data Collection of PM

DCAE, DMaaP, SDN-R, Link to Slide

Orange: 2

ATT: 2

China Telecom: 1

China Mobile: 3

Verizon: 3

Vodafone: 3

DCAE: on DMAAP (native Kafka support)

OOF: M

DCAE: L


code change: OOF

Code : DCAE


CCSDK: committed

SDN-C: committed

OOF: No Impact

DCAE: Committed (based on Nokia contribution) with dependency risk

OOF: Limited resources


AT&T, Nokia,

DCAE: Edge deployment support for R3, DDS-VES and new analytic platform (flink) not committed due to resource constraint



ON TRACK & CODE SUBMITTED

Code is developed & Submitted.

5G/performance Analysis and Optimization

Bulk PM

 DCAE, DMaaPLink to Slide
DCAE: on DMAAP-DRDCAE:L

code change: DMaaP

Code change: DCAE

DCAE:  DataFileCollector- Committed (based on Ericsson Contribution) with dependency risk

PMMapper - Partial Commit (Based on Ericsson contribution) + dependency risk Not a hard requirement


DCAE: Dependency on DMAAP-DR + PMMapper (Stretch goal)


AT&T, Ericsson



ON TRACK

DMaaP Data Router

ON TRACK

File collector available but with a few pending tasks
Update form Vimal on Oct 4: File collector on track.
POSTPONED

PM Mapper postponed to Dublin at M3

5G/performance Analysis and Optimization

Optimization Framework Enhancements (Placement, Formulation, Solving)

 OOF

Link to Slide

OOF: Mcode change: OOFOOF: Committed to SON
AT&T, Nokia, Reliance Jio

ON TRACK

All code has been submitted

5G/Network slicingWithdrawn from Casablanca release by the requirement owner

Orange: 3

ATT: 3

China Telecom: 1

China Mobile: 2

Verizon: 2

Vodafone: 3









Centralized Representation and Consistent ID of Cloud Regions,

Plan B, Phase 1: Centralized Representation of Cloud Regions

SO, Integration



Centralized Representation and Consistent Identification of Cloud Regions In ONAP

Orange: 1

ATT: 2

China Telecom: 2

China Mobile: 3

Verizon: 1

Vodafone: 1



code :

SO, Integration


  SO: committed based on Intel's contribution

  Integration: committed






To align MVP, propose alternative action plan B: break this requirement into 3 phases.

Phase 1 is to centralize the representation of cloud regions;

Phase 2 is to apply consistent ID across all related ONAP projects.

Phase 3 is to correlate and align dcaeLocation to AAI's cloud region. This phase requires further discussion, hence not listed here.

Note on "Intel's contribution": This is the synergy effort with HPA, no further special changes needed here. hence this can be deemed as a dependency on HPA's impact on SO.

SO: will be ready to test soon.

Integration: Not started yet.


Centralized Representation and Consistent ID of Cloud Regions,

Plan B, Phase 2: Consistent ID of Cloud Regions

SO,VID,SDNC,OOF,VFC, UUI,MultiCloud.Centralized Representation and Consistent Identification of Cloud Regions In ONAP

Orange: 1

ATT: 2

China Telecom: 2

China Mobile: 3

Verizon: 1

Vodafone: 1

VID/SDNC: on SO

SO/OOF/VFC: MultiCloud

VID: XS

MultiCloud: S

VFC:S

code :

SO,VID,SDNC,OOF,VFC,

UUI,MultiCloud

 SO: not committed

 VID: Not Committed

 SDNC: Not committed

  OOF: Committed

  MultiCloud:Committed 

  VF-C :Committed

  UUI: committed

SDNC: Limited resources

VID: requires additional resources



MultiCloud: Ready to test

VFC: not started yet

UUI: not started yet

Edge Automation Through ONAP (EA)A&AI, Multi-Cloud, OOF, SO

Edge Scoping MVP for Casablanca - ONAP Enhancements

  1. Cloud-agnostic Placement/Networking & Homing Policies (Phase 1 - Casablanca MVP, Phase 2 - Stretch Goal)

Orange: 3

ATT: 3

China Telecom: 3

China Mobile: 3

Verizon: 2

Vodafone: 1

OOF: on MultiCloud & SO

Multi-Cloud: on A&AI



SO: XS

AAI: XS

OOF: M

Multi-Cloud: M-L

Code: OOF, Multi-Cloud, A&AI, SO

Test: Integration (vFW use case)

Casablanca MVP:

  • OOF: Committed
  • Multi-Cloud: Committed
  • A&AI: Committed
  • SO: Committed




M4 on target in relevant projects

Integration Test Plan in Progress: HPA & Cloud Agnostic Intent - R3 Test Plan (In Progress)

Edge Automation Through ONAP (EA)Multi-Cloud

Edge Scoping MVP for Casablanca - ONAP Enhancements

2. Edge Scoping MVP for Casablanca - ONAP Enhancements#ONAPEnhancements-AggregatedInfrastructureTelemetryStreams(AlignswithHPArequirements,CombiningeffortswithHPA)

Orange: 3

ATT: 3

China Telecom: 3

China Mobile: 3

Verizon: 2

Vodafone: 1


Multi-Cloud: M-LCode: Multi-Cloud

Casablanca MVP:

  • Multi-Cloud: Committed



M4 on target in relevant projects

Start Small MVP "Node metrics and HPA metrics from Grafana dash board"

No plan for integration testing.


(star) T-Shirt Size: Ballpark estimation for assessing the development/testing activities performed by the project team; not the integration team

  • XS - <4 Man/Weeks;
  • S - ~6 Man/Weeks;
  • M - ~8 Man/Weeks;
  • L - ~12 Man/Weeks;
  • XL - > 12 Man/Weeks.

Non Functional Requirements 

Non Functional RequirementsOwnerSub-categoryProject Impacted for CasablancaLink(s) to High Level Design (HLD) /Low Level Design (LLD) (if any)Dependency (from/to) another project(s)T-Shirt Size (XS, S, M, L, XL)*Project's Impact: Test Only (TO), Code (C)Committed (C)/Partially Committed (P) or not (N) per Impacted projectsIf Partially or not Committed, then what are the gaps per impacted project (people/FTEs; HLD/LLD; etc)Company EngagementNotesM4 Status
S3P
  • Performance
  • Stability
  • Resiliency
  • Security (see below)
  • Scalability
  • Manageability
  • Usability

Likely ALL depending upon TSC determination of new level requirements per category


Materials

Usability:  New API’s adhere to Versioning strategy

Versioning & API Documentation Recommendations

Manageability: Adherence to ONAP Logging Spec v1.2 (implementation of the spec will occur in Dublin - Logging Dublin Scope)




Portal: on AAF, MUSIC, OOM

VID, Policy, SDC, AAI: on Portal

Portal: XLPortal: Code

Portal: Not Committed

APPC: Partial

DCAE: Partial

SDC: committed

VID: Partial (depends on Portal)

AAI: Partial

Portal: See Risk #2

APPC: Please refer to M1 Planning template for details

DCAE: Refer to DCAE R3 M1 Release Planning#PlatformMaturity for details

AAI: Please refer to AAI R3 Platform Maturity




Portal: IBM (only forAngularupgrade - shown interest, but not committed yet)

Portal:

1) Looking for resources who can help with adhering logging standards, API versioning and kubernetes deployment of Portal dockers.

2) Furthermore, Portal requires a security expert in addressing angular upgrade to address the Nexus-IQ reported vulnerability (the angular upgrade its self is XL t-shirt size task).


Security

Note: This does not cover what is in S3P. However, based on that it is expected to have a certificate or use CADI to get certificates to enable secure communication

Pluggable authentication and Authorization (Use of CADI and ?):

  • JAVA projects to use CADI client and enforcement point
  • Non-JAVA projects:Wait until there is multi-language.
  • All projects either need to have certificates (for secure communication) (based on a common trust store of AAF).  The certificate distribution can be part of deployment mechanism and will be further detailed.

Secure communication toxNFs(Security for 5G Use cases). DCAE, APPC, VFC? VNF requirements. (Secure Communication to Network Functions)
- TLS and/or SSH for netconf (APP-C, SDN-C, CCSDK)
- HTTPS security for VES (DCAE) (with certificates, slowly deprecating username/pasword)

  • Description of how the xNFs will get their certificates (VNFreqs). 

Vnf package security following SOL 004: SDC, VNFreqs, VNF SDC


Materials

CADI/AAF Integration:


Portal: on AAF

Test coverage (js):

(1) js Sonar plug-ins activation

(2) min. 3 additional containers per application

=> Jenkins enhancements

(3) Maven build to be updated

Risk #1

DMaaP on AAF

DCAE on AAF, OOM,DMAAP

OOF on AAF

Portal (CADI): M

DCAE: XL

SDC: L

Test coverage (js):

All: M/L


Portal: Code

SDC: code

VID: Code

Portal: Not Committed

APPC: Partial

OOF: Partial

DCAE: Not Committed

SDC: Partial

VID: Partial (depends on Portal)

AAI: Partial


Portal: See Risk #3

APPC: Please refer to M1 Planning template for details

DCAE: Refer to DCAE R3 M1 Release Planning#PlatformMaturity table for open issues/question with current proposal

OOF: Please see OOF Casablanca M1 Release Planning Template

SDC: because of the size of the sdc source code we will be able to reach only 10% unit test coverage on the Javascript. VNF package security missing information.

AAI: Please refer to AAI R3 Platform Maturity


Portal: Looking for resources who understand the AAF based certificate management to upgrade using CADI client in Portal.


OOF: Need more clarity on AAF support for python projects in Casablanca


Upgrade (from Beijing to Casablanca)



All: XL

APPC: Not Committed

CLAMP: Not Committed

DCAE: Not Committed

SDC: not commited

VID: Not Committed

AAI: Not committed

APPC, CLAMP, Portal, SDC, DCAE, VID, AAI: Lack of resources require additional information (does it include rollback, retrofit, no impact on run-time, etc)?





Architecture Alignment

  • API improvement
  • Realtimestreaming
  • K8S Support (for VNFs)



DCAE on DMAAP (for DR)

DCAE:XL

DCAE:Partial Commit (New service committed based on Ericsson/Nokia)

SDC: partial

MultiVIM: Committed

External API: Committed

SO: Partially committed

A&AI: partially committed

CCSDK: committed

DCAE:  DDS-VES and new analytic platform (FLINK) not committed due to resource. xNF-DCAE authentication not committed due to open issue listed under security.

SDC: policy designer not planned for Casablanca, ETSI compliance only sol004 is planed. PNF suport will be done ontop of the existing capabilities. RTC stretch goal. DCAE-DS committed. Flow designer committed.

ExtAPI: Interlude is a stretch goal

SO: "decomposition" committed; "service instantiation" stretch goal

A&AI: abstract topology sync-up committed



Reviewed and accepted at M3 reviews
HEAT support

HEAT-based ONAP deployment support should be dropped once OOM-based ONAP deployment's issues are fully identified and resolved.

Recommendation from TSC: keep supporting HEAT in Casablanca for testing and integration purposes. However, HEAT won't be a gating item at Release Sign-Off.


Portal: on OOM

Portal: S

SDC:S

Portal: Code

SDC: code

Portal: Not Committed

APPC: Will support Heat partially

OOF: Support HEAT for testing

SDC:committed

VID: Partially

Portal: See Risk #4
Portal: Switching CSIT jobs from using HEAT based to OOM based requires resources who can understand the current setup.
Internationalization language supportTao Shen
  • User Experience

Design language/internationalization component in Portal and provideserviceapistopartnering apps like Policy, VID, SDC, AAI

Note: This will need to go through the whole process (Architecture review,...) to understand whatthesdk will be providing and dependenciesonother ONAP project (Portal, SDC,...)

As per Lingli and Tao from chinamobile, this is reviewed and approved by Arch Team.


UsecaseUI: on PortalPortal: LPortal: Code

Portal: Partial

APPC: Not Committed

CLAMP: Not Committed

SDC: Not committed

VID: Not committed

Portal: Limited resourcesPortal: AT&T, ChinaMobilePortal: Policy, VID, SDC, AAI can choose to use this Internationalization feature based on their capacity. Only UsecaseUI team is committed to develop and use this feature for now in Casablanca.

POSTPONED

Due to lack of resource, this is postpone to Dublin Release

Testing
  • Unit tests
  • CSIT tests

Most UI projects with javascript.

Recommendation from TSC: This is related to Code Coverage: recommendation is to keep 50% Code Coverage for Casablanca including JavaScript. (In Beijing Release code coverage was only covering Java and Python code, not javascript)


Linux Foundation Unit test and CSIT coverage framework,

Policy, VID, SDC, AAI: on Portal, DCAE (for JavaScript coverage)

Portal: XL

SDC:S

VID:S

Code: portal, SDC, VID


Portal: Partial (no Javascript)

APPC: Partial, Java code will maintain 50%, no commitment for Javascript

CLAMP: Partial, Java code will maintain 50%, no commitment for Javascript

DCAE:Partial (except javascript)

SDC: maintain 50% coverage for java and python

add 10% coverage for UI(java script)

VID: maintain 50% coverage for java

add 10% coverage for UI (java script)

AAI: Partial, Java code will maintain 50%, add 10% coverage for sparky (javascript)

Portal, APPC, CLAMP, DCAE: See Risk #1


Portal: AT&T, IBM, TechM

 modeling Hui Deng

 SDC: needs to support composite pattern in R3

SDC/SO/A&AI needs to support Service Order, Service Catalogue, service scaling

Modeling runtime needs to be supported by A&AI in release 3





SDC:not committed

SO

A&AI - changes to the run-time schema require significant refactoring in all of AAI's client applications. That refactoring might be planned and addressed in R4; for R3, perhaps mapping existing runtime schema to new model definitions can suffice?

SDC: late submission to the requirements for Casablanca, not clear on what are the requirements from sdc.


(star) T-Shirt Size: Ballpark estimation for assessing the development/testing activities performed by the project team; not the integration team

  • XS - <4 Man/Weeks;
  • S - ~6 Man/Weeks;
  • M - ~8 Man/Weeks;
  • L - ~12 Man/Weeks;
  • XL - > 12 Man/Weeks.



13 Comments

  1. Not sure what category to put this in?

    VNFRQTS  received a comment  captured in VNFRQTS-224 suggesting that VNF metadata be captured in YANG v1.1 My understanding ( and current VNF Requirements for  the ONAP platform) currently supports YANG 1.0

    I believe YANG 1.0 would  need to continue to be supported. I am not sure what the impact of providing additional support of YANG 1.1 would be across the ONAP platform components - but I suspect that several components would be impacted. I expect  onap  would need to support YANG 1.1 at some stage - I'm just not sure if Casablanca is the appropriate release.

    This seems to be an example of a somewhat finer grained feature alignment exercise than the features listed above.  I expect there may be similar cases of upstream versioning upgrades that may be required from time to time. Is this the appropriate mechanism to get alignment on these?

  2. There is some potential confusion around the DBaaS.  OOM has already started this with our work towards common DB charts (see kubernetes/common) which will be shared across projects and optionally with shared instances if the project teams agree.  MUSIC may have a role in geographic diversity but this doesn't necessarily imply DBaaS.

    1. Roger,

      From my understanding, when the MUSIC project was initially proposed, there were suggestions that we should be part of OOM. Both the MUSIC team and the OOM team at that time were clear that our roles were distinct: MUSIC will manage state and OOM will manage the entire life cycle management of components. Consistent with that, we believe that the MUSIC team should perform the role of DBaaS. That will also allow us to cluster these solutions more efficiently across sites – our main USP. We would welcome OOM's participation in the MUSIC project to help realize this. 

      What do you think? 

      "Tagging" other interested parties: Brian FreemanRyan HallahanTim O'KeefeBrian FreemanCatherine Lefèvre

      Thanks,

      Bharath. 

      1. We also agreed that use of MUSIC is optional for each team.  The OOM team would be happy to help add MUSIC to kubernetes/common for project teams to use if they wish but there will be other options available (non Cassandra for example).

        1. Absolutely! The MUSIC team is not proposing to enforce Cassandra on all teams. We wish to support MariaDB as a service (and in the future Postgres etc) as part of the MUSIC suite of solutions. The only difference is: if the MUSIC team says it supports MariaDB as part of its Dbaas solution, then we are responsible for integrating projects who wish to use MariaDB, ensure MariaDB is resilient, it scales out etc. We are willing to take this responsibility and believe it is part of state management. Does that make sense?



  3. Hi Scott,

    In the scaling use case, Multi-VIM/Cloud will also be impacted. SDN-C or APP-C should call Multi-VIM/Cloud to request additional resources for the scale out operation. Happy to chat more.

    Thanks,

    Ramki & Gil



    1. if nothing changed from Beijing release, Scaling will call Multi-VIM/Cloud API with the same one call by first time orchestration. In that case Mulit-VIM/Cloud should only be test only, no further code needed, hope this information could help evaluate the effort from multi-VIM/cloud perspective.

    2. As part of the homing and capacity check OOF should call Multi-VIM/Cloud to determine if there are enough resources to do the scaling action.  Neither SDNC nor APPC make scaling requests.  At this point in time it doesn't look like the homing and capacity check will make it into Casablanca, so we have not updated that flow yet.

      1. FYI. The capacity check by OOF to Multi-VIM/Cloud is already implemented in Beijing Release and will be there in Casablanca Release. Multi-VIM/Cloud is not  aware whether it is a capacity check for first time orchestration or scaling out.

        So could you clarify the statement about "At this point in time it doesn't look like the homing and capacity check will make it into Casablanca" ?

  4. After reviewing the S3P requirements with several PTLs, I've aggregated several pieces of feedback that require further detail/clarification before PTLs are able to commit.  Tagging Jason Hunt as the owner of the deck, but welcome feedback from everyone.


    For Slide 3:

    1. The following requirement needs clarification prior to commitment:

    Continuously retaining no critical or high known vulnerabilities > 60 days old 

    -          Specifically, how is 60 days being measured (when does clock start/stop)?  In particular, PTLs have asked how this timeframe works with our existing 6 month release cycle in ONAP (e.g., are we going to issue interim releases/patches, etc.?).

    -          Also, how are PTLs supposed to deal with false positives (is there a process in place for these?).  What about vulnerabilities that get pulled in as part of other open source projects that ONAP projects use (e.g., ODL)?

     

    2. The following requirement needs clarification prior to commitment:

    All communication shall be able to be encrypted and have common rolebased access control and authorization.

    -          Specifically, what does this include.  Is it just component-to-component API calls? More than that?  PTLs have raised questions about securing things like like DMaaP topics and component calls to backend DBs like Cassandra, which may be difficult to secure at the moment?

    -          What about Python-based projects?  AAF doesn’t have a Python client at the moment?

     

    3. Can we please update the slide to move the following line into the “Stretch Goal” column as discussed at the F2F?  It has caused some confusion.

    Desired expectation is full CII badging silver level, if not 75% towards that.


    For Slide 4:

    4. Can we please enumerate somewhere what the “closed-loop projects” are that Level 2 applies to?  This has been interpreted differently by various PTLs.

     

    For Slide 6:

    5. The following requirement needs clarification prior to commitment:

    A component can be independently upgraded without impacting operation interacting components

     

    6. The following requirement needs clarification prior to commitment:

    Component configuration to be externalized in a common fashion across ONAP projects

    -          Is this a dynamic or immutable external configuration?  Do we have a common approach, e.g., using config maps in kubernetes? Or will it vary for every single component?

     

    7. For adherence to the ONAP Application Logging Specification v1.2, is there a proposal for how this will be measured?  Are we expecting perfect 100% adherence, or perhaps a percentage (e.g., 80% adherence) should be the target for this release?

     

    For Slide 7:

    8. The following requirement needs clarification prior to commitment:

    Projects contribute to end-to-end tutorials

    -          What is meant by E2E tutorial?  How will this be measured? Who (what project) ultimately owns the tutorials that projects are contributing to?


    1. Thanks for the thorough review Ryan Hallahan.  Keeps us all on our toes!

      As a general statement, I would like to ask the community to sign up as "owners" for each of the requirement categories to provide more clarification and supporting tools.  Some will be easy (like the Security Subcommittee for the security requirements), but will need volunteers for others.

      • Slide 3 – I will defer to the security subcommittee (Stephen Terrill) for answers to questions #1 & #2, but I will update the slide about CII Badging silver as stretch with 75% toward silver as the required (question #3).
      • Slide 4, Question #4 – The Control Loop Subcommittee (Pamela Dragosh ??) should have the final say, but looking at their documentation, I think the following is a good starter list, though I'm not sure if A&AI, CLAMP, dMAAP, multi-VIM should be included.  This is based on the spirit of the requirement that performance matters most for runtime closed loop operations:
        • DCAE
        • Policy
        • Orchestration & Controllers (SO, APPC, VFC, SDNC)
      • Slide 6, Question #5 – fair question.  My interpretation from the initial discussion is that you could deploy a new version of a component (assuming backwards compatible API) without taking down any other component.  My thought is that this can be done with OOM/Kubernetes capabilities like rolling upgrades, etc.
      • Slide 6, Question #6 – by "dynamic" do you mean the ability to change the configuration and have components automatically pick up those changes without a restart?  I don't think that was intended in the spirit of the requirement.  As for implementation, the recommendation would be to use Kubernetes ConfigMap.  I'd like the OOM team to "own" this and the previous requirements.
      • Slide 6, Question #7 – I would defer to the Logging Project (Michael O'Brien (Amdocs 1705-1905) ??) for how to measure this.  If there is concern about full compliance, please recommend what might be a reasonable goal for Casablanca.
      • Slide 7, Question #8 – ONAP University would've been the logical owner here, but as it is deprecated, we would need an owner.  Would Documentation (Gregory Glover Rich Bennett) be willing to own an E2E tutorial? If not, I think we will need to defer this requirement.
      1. Jason Hunt  and Ryan Hallahan comments on Slide 7 questions/answers...

        What is meant by E2E tutorial?

        The tutorial scope since R1 has included:

        • configure a cloud infrastructure,
        • create ONAP on the infrastructure,
        • design, distribute, and instantiate a service on the platform, and
        • observe the service operation across closed loop control actions.


        Would the documentation project be willing to own an E2E tutorial?

        • With the documentation contributors committed to Casablanca I don't think we have the breadth of expertise or capacity to maintain the frequent changes in a tutorial with the scope above.  Changes continue to be made at multiple levels each release of ONAP and as the community tries to run the tutorial in environments where external dependencies are changing.
        • What might be easier to deliver and as valuable to a range of new users who want to learn about ONAP is improvements (linkages and maintainability) in existing content.  The documentation project contributors, 60+ other project repository contributors providing parts of the documentation, and some ONAP committee wiki contributor content could be better organized as release documentation to make it easier for a range of new users (e.g. varying levels of scope, need, time, resources to test, etc.) to learn about ONAP.


        How could this be measured?

        • For each Casablanca Use Case, the following must exist in Gerrit, in an easily maintained form (e.g. editable source with common open source tools) and be published in the Casablanca Release documentation at ReadTheDocs:
          1. Sequence Diagram for the use case (e.g. https://docs.onap.org/en/beijing/guides/onap-developer/use-cases/vfw.html)
          2. Formal references from the sequence diagram page/sections to other release documentation including Architecture/Design patterns, data models, platform components, APIs that are assumed in the use case.
          3. Some overview text that is created and reviewed by doc project contributors who understand the target audiences (e.g. a potential future contributor, designer of service running on ONAP, operator of an ONAP instance and services).



  5. Stephen Terrill/Security Team – Current security proposal presents couple of options for enabling security (direct AAF vs CADI for java vs Istio) - each requiring different level of effort though and some are language/platform specific. It will help to have recommendation for consistent solution rather than individual project needing to figure out different approaches. The presentation/WIKI link are also missing some key information on how the certificate (from AAF) will be distributed to support both dynamic and static deployed components in ONAP; and to enable mutual TLS between components in ONAP and external (e.g vnf/pnf) – what is recommended process to ensure respective client cert/trust are loaded?

    The slidedeck has couple of WIP items – would appreciate if these can be addressed soon as it will help teams making their assessment.