This wiki page is explicitly set up as a scratch-pad of feedback that the ONAP TSC Members will use to identify, and collate initial feedback to ONAP project proposals as we all prepare for the first set of Project Creation Reviews starting on June 8th and 9th 2107.
...
Service Orchestrator (5/14/17)
(Alla, Andrei)
- Closed Loop management and orchestration: applying Event/Model/Policy approach causing service re-plan
(Stephen)
- Scope is rather clear. It would be good to state which APIs the project feels it is responsible for defining (it states later which it feels it uses).
- JIRA prefix: I suggest we drop MSO now as I understood its decided as SO.
...
- Potential Overlap with VNF SDK for VNF validation tooling or testing framework.
- Need clarificatin with the overlap between modeling and this project regarding the VNF template (HEAT and TOSCA).
ICE
(Alla, Andrei)
- VNF package validation, VNF testing based on agreed KPI's;
- Supporting ETSI NFV standards and TOSCA specifications;
- VNF store/market place;
- VNF certification;
- Leveraging SDC platform and SDC/ONAP Portal
(Jason Hunt)
- I believe I understand the difference between ICE and VNF SDK, as it appears that VNF SDK will provide all the tooling to implement the validation program, but the ICE/VNF Validation Program will establish the community and processes for validation. Is this correct? Because of the tight synergies of these projects, would you consider merging them? Perhaps VNF SDK and VNF Requirements could be subprojects under the VNF Validation Program?
- (CJD) The skillsets (and interests) of the committers are different. Some people have experience with code, others with writing guidelines, and others with developing certification/compliance programs. While there will be a relationship between the projects, we think that this separation makes sense from a committer and governance perspective.
- (
...
- VNF SDK and ICE should be merged. VNF-SDK starts almost from scratch, so it would be
- ES) To add a bit to what Chris added. We have discussed in depth around the division between the VNF SDK & Tooling and ICE project. There may be some overlap between the projects as far as tooling but the close work between the projects will allow us to make sure it is ironed out during the course of the projects. The long-term plan is to leverage the VNF SDK & Tooling and VNF Requirements as basis for the VNF Validation Program. There may be items inside the VNF Validation Program which will not be covered by the VNF SDK & Tooling which would then mean it would be supplemented under the VNF Validation Program umbrella. Additionally any tooling which exists in the current ICE implementation will be contributed into the VNF SDK & Tooling project.
(Roberto Kung)
- VNF SDK and ICE should be merged. VNF-SDK starts almost from scratch, so it would be easy. Some links to be made do OPNFV (Dovetail, Program CVP).
- Will depends very much on technical decisions from other projects that may impact VNF guidelines.
- (CJD) VNF SDK is part of the OPEN-O Mercury release (not from scratch). Note that we made changes from the original project proposals - code development (tools) will occur in VNF SDK and validation program development (governance) will occur in ICE.
...
- +1 to VNF SDK and ICE should be merged as a unified tooling project.
- (CJD) that's the VNF SDK proposal. ICE has been updated to focus on the validation program governance.
- (ES) The division of the projects have been discussed between the teams. We are aware of the close linkage between these two projects (as well as other relevant projects) yet believe it will be ironed out during the course of the projects.
- Either way, the tooling for packaging and validation implemented by these tooling projects should be fully complying with the unified modeling (modeling project) and guidelines/specifications procedural requirements (VNF requirements) so that they are not diverging from each other.
- (ES) Any validation will be based the combined efforts of the platform teams including modeling. The initial scope of the VNF Validation Program aims to focus on the VNF Package for on-boarding yet the process defined is not limited to that only.
- It seems that in the revised project proposal focuses more on the program and test cases, but still contains tools/testing framework, which has potential overlap with VNF SDK, e.g. what tools to be used when conducting VNF lifecycle test for validation, etc..
- (
...
- ES)
...
- There
- There may be an initial overlap of the code made available in the repos yet the long-term plan is to leverage the VNF SDK & Tooling and VNF Requirements as basis for the VNF Validation Program. It is likely necessary to complement that tooling with validation process specific items. The details around the delineation will be ironed out during the project with the continued close contact between the various teams involved.
(Ranny Haiby)
- There need to be multiple levels of certification. ONAP compliance is more complicated than a binary yes/no. For example, a VNF may be ready for instantiation by ONAP, but not ready for monitoring by DCAE, or life-cycle-management by the APP-C. So the project should clearly state what are the aspects of certification, and what certification "packages" may be available.
- (ES) Agree that there are multiple levels of validation/certification. The initial focus is to establish the governance of the project and define a process allowing anyone to obtain a ONAP Compatible Label for their VNF. We will also focus on making sure we establish process to extend the scope of the validation to cover additional scope and aspects. For the initial release the main focus is on the VNF Package content and validity though.
- -1 to the VNF-SDK/ICE merge proposal. The two projects will likely have different repositories, skill set, etc. The fact that the SDK serves ICE does not necessarily mean they must be merged. ICE can use additional tools than the VNF-SDK, and the VNF-SDK may be used outside the scope of ICE
- (
...
- ES) Agree that even though there is a close relationship yet are by their nature very different. I do actually believe it to be more than likely we will leverage additional tools than what will be in scope for the VNF SDK & Tooling yet it is important to minimize any such tools to the extent possible.
(Mazin Gilbert)
This comment is for both ICE (verification) and VNF-SDK. Please ensure there is no overlap in the functions. You should also discuss potential technology (tool) overlap.The two components need to work in a streamlined approach. Also connect with the SDC project to ensure both components intgerate into that architecture. .
- (ES) I should have covered most of this in my comments above. The VNF SDK & Tooling, VNF Requirements, SDC and ICE project teams have discussed in depth the necessary close collaboration between the projects and the need to manage any potential overlap. The long-term plan is to leverage the VNF SDK & Tooling and VNF Requirements as basis for the VNF Validation Program. One key item as part of the first release of the VNF Validation Program is to define that plan. There may be items inside the VNF Validation Program which will not be covered by the VNF SDK & Tooling which would then mean it would be supplemented under the VNF Validation Program umbrella. Any tooling which exists in the current ICE implementation will additionally be contributed into the VNF SDK & Tooling project.
(Chris) We discussed this at length between the VNF SDK/ICE teams. ICE/Verification will focus on the verification program. VNF SDK will focus on the tools (including the ICE tools) and will align with SDC.
VNF-SDK
(Alla, Andrei)
- VNF package onboarding;
- Supporting ETSI NFV standards and TOSCA specifications;
- Leveraging SDC platform and SDC/ONAP Portal
(Jason Hunt)
- I believe I understand the difference between ICE and VNF SDK, as it appears that VNF SDK will provide all the tooling to implement the validation program, but the ICE/VNF Validation Program will establish the community and processes for validation. Is this correct? Because of the tight synergies of these projects, would you consider merging them? Perhaps VNF SDK and VNF Requirements could be subprojects under the VNF Validation Program? Or are there other uses of VNF SDK outside of the validation program?
- Can you clarify how this tooling will be provided? Will it be another running component of ONAP, accessible from the ONAP portal?
- Can you clarify the role of the network function repository? Is the thought for this to be run separately by a third party? If not, and it is part of an ONAP installation, how is it different from the existing catalog of onboarded functions?
...
- Let's consider separate proposals for the Labs versus Integration. Labs should define the minimal assets required to stand up a lab (Physical, Power, Networking, People, Software).
Helen Chen: Agreed, even thought Integration project and Labs have a lot of overlaps regarding to CI / CD, Use case deployment, configuration, service template design, etc., and we may end with the same group of people. These two projects will work closely: Integration will use the Labs built by the community. So far, basic pod definition has been proposed. Based on approved use cases, we will work with the team to finalize the minimal lab requirements.
Analysis
DCAE (5/11/17)
(Roberto Kung)
...
- Could the proposal clarify the unified model-driven approach? How are the data models used by AAI, APIs, or blueprints updated?
- Include in scope: Modeling and Design (concept for multiple projects: CLAMP, SDC, AAI, Network Functions Change Management, External API Framework, External System Registry
- Include in Scope: Application Modeling (VNF modeling) (e.g. YAML based) for managed VNF's as supported by APP-C that leverages Closed Loop management including application management
- Small: the text uses OPEN-O and OpenECOMP. As the project description should survive the first release, perhaps look at wording to avoid referring to those terms as they should be deprecated in ONAP. e.g. "The project will produce unified and consolidated data models".
- Under "scope" The reference to R1 may better be removed. It may imply that the data model will be designed to address these use cases only and ignore the rest, which I am sure was not the intention. This information should go into the release planning, not project definition.
- Question: What about backwards compatibility for ECOMP and Open-O data models? Will there be a new model to replace both? If so, is ONAP expected to support only the unified model? Or support the new as well as the two old ones?
...
- Could the proposal clarify the unified model-driven approach? How are the data models used by AAI, APIs, or blueprints updated?
(Alla, Andrei)
- Include in scope: Modeling and Design (concept for multiple projects: CLAMP, SDC, AAI, Network Functions Change Management, External API Framework, External System Registry);
- Include in Scope: Application Modeling (VNF modeling) (e.g. YAML based) for managed VNF's as supported by APP-C that leverages Closed Loop management including application management
(Stephen)
- Small: the text uses OPEN-O and OpenECOMP. As the project description should survive the first release, perhaps look at wording to avoid referring to those terms as they should be deprecated in ONAP. e.g. "The project will produce unified and consolidated data models".
- During the release planning, it would be good to have the plan of when to deliver what models for the needs of other projects to use.
- I understand that the deliverables are both models, as well as code in the form of tools. Should they be in the same repo, or different repos (question, not a statement). consider separating tooling from models in repos
- The number of committers is very high, perhaps 1-2 per company
- Be clear on the tools to be as a deliverable, and the APIs. e.g. a model passer .
...
Reasonable and Well defined Scope:
- Scope seems rather large. Not clear on what is for the first release, and interactions/dependencies with DCAE, policy, SO, Controllers. .....
- More detail on what test is
- could be clear on what deliverables are required to support the use cases.
- What is the scope of the catalog module
Identification of SW modules and APIs being developed and delivered to other components
- It would be great to be clear on the modules delivered by this project
- The connections to other projects should be clarified clearly.
- Are there APIs that the project feels it is responsible for, or does it use the APIs defined by others?
Follow project and LF guidelines for contributors/committers
- Perhaps 1-2 committers per company
Identification of dependences and assumptions on other components and open source
...
Intentional and unintentional overlap
- Any relation to ICE?
overlap with external opensource efforts
...
Could the proposal describe the scope of the catalog module?
(Alla, Andrei)
- SDC should be an umbrella for all Design time parts from other Projects (CLAM, Policy, Converged ICE & VNF SD-K);
- SDC is a platform for all the modeling and design in ONAP and provides the interactive tool for design and automation for on-boarding.
(Stephen)
- It would be great to be clear on the modules delivered by this project.
- The connections to other projects should be clarified clearly.
- Are there APIs that the project feels it is responsible for, or does it use the APIs defined by others?
- Perhaps 1-2 committers per company
- More detail on what test is.
- Scope seems rather large. Not clear on what is for the first release, and interactions/dependencies with DCAE, policy, SO, Controllers. ......
- Not clear what deliverables are required to support the usecases
(Zhaoxing)
- Could this project proposal clarify how to support the Telcom use case(VoLTE), for example, how to onboarding TOSCA based VNF and use it as building block for service design?
- Could this project proposal clarify its relationship/dependency with ICE? It seems that the ICE project will provide guideline/process definition for certification and this project will provide tools to support ICE?
...