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?
(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.
...
(Chris) We discussed this at length. 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?
...
- 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 .
...
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?
...
Policy Framework Project Proposal (5/11/17)
(Stephen)
...
- Pamela Dragosh - yes we can update the API's.
...
- Pamela Dragosh - sure we can consider other committers. Initial thought was that for Release 1, best to have only folks that know the code. But the project is designed to evolve the Policy Framework and address its current limitations, which will require us to expand the list of committers.
...
- Pamela Dragosh - I don't think we had enough time to clarify that. My thought is that the project should define the flow for all the types of policy required by ONAP. For example, how it is expressed/captured, when it translated, which component calls the API to create/update it, etc. That would at least involve documentation of that flow. I will start discussion on how to clarify this.
...
Chris)
- Clarity: Project description and scope are unclear. They were written from the perspective of someone who is familiar with the module in ECOMP, but many of the TSC members are not as familiar and we need more clarification. Please add more detail about the big picture (problem you're solving and vision). Also, please clarify what you're delivering (code, requirements, etc.).
- Overlap: How does this relate to other projects? Are you developing APIs? Are you producing requirements that you expect others to implement (and did they agree)?
- Risk management: It appears that you have sufficient resources. We would like to see committers from different companies. It would be helpful to clarify your deliverables - is there a subset that can be delivered in the R1 timeframe?
- Relevance and prioritization: this is relevant to the ONAP release.
(Stephen)
- It would be great to state the APIs that this project feels it is responsible to define
- Pamela Dragosh - yes we can update the API's.
- If possible, consider a committer from another company as well (this shouldn't block approval).
- Pamela Dragosh - sure we can consider other committers. Initial thought was that for Release 1, best to have only folks that know the code. But the project is designed to evolve the Policy Framework and address its current limitations, which will require us to expand the list of committers.
- In the scope there is text on classification of policies. What is unclear to me is the deliverable from that. Is it a document? is that in internal deliverable?
- Pamela Dragosh - I don't think we had enough time to clarify that. My thought is that the project should define the flow for all the types of policy required by ONAP. For example, how it is expressed/captured, when it translated, which component calls the API to create/update it, etc. That would at least involve documentation of that flow. I will start discussion on how to clarify this.
- Seems to have a good level of resourcing
- Is there any models that this is dependant on, or expected to define?
- Pamela Dragosh - Yes. The current Policy seed code is model-driven and we utilize models from the DCAE team in order for the DCAE components to be policy-driven. We have used EMF in the past, but are phasing that out in support of TOSCA/JSON approach. We expect to be the team that defines how policy is expressed if there are any specific models that are going to be used to express policy. (i.e. the outcome from the Modeling Project).
...
Policy Driven VNF Orchestration (5/12/17)
(Chris)
- We understand this is being rolled into Policy Framework
- Clarity: The scope is unclear. What exactly are you delivering?
- Overlap: How does this relate to other projects? Are you producing requirements that you expect others to implement (and did they agree)? Is this feeding into SNIRO?
- Risk management: It appears that you have sufficient resources. As part of Policy Framework, this could be a longer-term deliverable. Any delay wouldn't derail R1.
- Relevance and prioritization: this is relevant to the ONAP release.
(Stephen)
- Mainly the relation and interaction with CLAMP and SNIRO is unclear in terms of deliverables, can these be considered to be placed into either of those?
- Is it clear how this will extend the policy framework, and what the deliverable will be. It would be good to be clear on that.
...
SNIRO Optimization Framework (5/11/17)
(Chris)
- Clarity: Project description and scope are clear. Please finish filling out the Key Project Facts section.
- Overlap: How does this relate to CLAMP and Policy Driven VNF Orchestration?
- Risk management: Is there a subset of your functionality that can be delivered in R1? We would like to see you refine your committer/contributor lists. It would be good to have committers from different companies, but not everyone on your project should be a committer.
- Relevance and prioritization: this is relevant to the ONAP release.
(Stephen)
- As this provides a framework to be used by others, during the release planning phase, it would be good to sync with policy framework, CLAMP, others on the expected receives and uses of what is delivered here. It would be great already to give a hint at who the potential uses of the framework would be.
- Perhaps a max of 1-2 committeers per company. Great that there is a mix of companies though.
...