The exclusive purpose of this wiki page was to consolidate all TSC feedback during the original 30+ ONAP project creation reviews that occurred between June 8th and 9th 2107.
It is retained for historical purposes only.
General Feedback for All Projects
(Mazin)
Thank you for all your hard work.
As a general comment to all projects. Please be very clear on your scope. Identify on who the lead is and committers.
Committers need to be individuals who have knowledge of the code and have contributed to it. Also state whether
you plan to contribute seed code that you have and the maturity of that code. Risk assessment and clarity are critical
dimensions to TSC approvals.
(Phil Robb)
Similar to Mazin's comment, please choose your initial set of Committers carefully. As a general rule, you should not have more committers than contributors. Please refer to the email I sent on this topic for more information.
Also, for your committers in particular, make sure you provide their gerrit IDs. The Linux Foundation Infrastructure Team will need this information to give them committer access rights within the build system.
Orchestration & Controllers
APPC Project Proposal (5/12/17
(Stephen Terrill)
- While obvious, it would be good to state in the project description and scope that this produces the APP-C module. E.g. This purpose of this project is to create the Application controller module.
- In the project description, it states the "APPC model will be based on ONAP TOSCA, YANG, ...". I assume this will have a dependency on the modeling project. Can we call out specifically what this project will contribute with the models vs uses. i.e. I was looking for whether this project felt it was responsible for a model, in alignment with the modeling project, Or would it use the models defined by the modeling project?
- The project description could go into more of what the project is about. e.g. To produce an application controller that : ...."
- In the scope, where it states that it "provides Generic LCM commands" it would be good to work in that this is an API that is the responsibility of this project.
- There is some text such as "Manage the VNF operational state including Blocking, Sequencing and Session Throttling" where the project is not really doing, but the model the project produces does, small but could be clearer. e.g. "APP-C will: bullet points.
- In the text for "how does this align with external standards/specification", I thought it also used YANG for the components of the southbound? (question, not a statement).
- General: Is there dependencies on the common controller framework that hasn't been called out? Either state the dependencies, or state how that is to be handled in the scope.
- General: There is the discussion around the alignment or relation to the VF-C, however I do agree that leaving this out for now until this is clearer in the architecture is fine.
- I think it would be good to call out the interfaces defined and used by the project. Note as there are interfaces common to all controllers, maybe the definition of the interfaces could be under the common controller framework project??? note: we need to ensure that this is done in such a way that the capabilities of one controller, or release, does not hold back the capabilities of other controlers.
- My view on the resources, committers is that this is ok (4 committers, 3 companies, a number of interested resources).
(Zhaoxing Meng)
- From the view of overall architecture, APP-C is used for VNF configuration. But the scope of APP-C proposal includes a lot of functionalities about the VNF Lifecycle Management. We need to make it clear how to do VNF lifecycle management from Architecture level first, then we can take a look at the scope of the APP-C to see if it align with the architecture.
(Chris Donley CJD)
- As noted by previous commenters, the project description and scope are unclear. It would help if you explicitly describe the problem you are solving and then your approach.
- Would you please provide more information on your support (or planned support) for TOSCA and ETSI NFV MANO?
VF-C: Virtual Function Controller (5/16/17)
(Stephen)
- Scope: Skeleton text of "provide the functionality" can be removed and replaced with "This project provides a VF-C that":
- I think it would be good to call out the interfaces defined and used by the project. Note as there are interfaces common to all controllers, maybe the definition of the interfaces could be under the common controller framework project??? note: we need to ensure that this is done in such a way that the capabilities of one controller, or release, does not hold back the capabilities of other controllers.
- As per the APP-C project, we need to state what models this is responsible for defining, vs what it uses. coordination with model project and app-c project.
- JIRA etc needed.
- It would be good to state either dependencies on the common controller framework, and or how that will be worked through.
- The committers need to be called out. (resourcing seems OK).
(CJD)
- Will you please fill out the key project facts section at the bottom? It will make it easier for LF to set up the repos and mailing list.
- It would help to include more information in the description.
SDN-C (5/12/17)
(Stephen)
- Scope: It would be good to clarify which interfaces are defined by this project and which it uses. Note: proposal to have the common controller framework defining the interfaces? (can be discussed).
- Scope: State which models this is dependant on, and which it is "responsible for" - coordinate with modeling project.
- General: It would be good to state which parts of the common controller framework this will use, or at least how that will be aligned.
- Resources OK.
- It seems a little high on the committers. There are several companies, that is great. Would it make sense to have one per company?
(CJD)
- Would you please clarify the scope of the project? You say global controller that manages network resources. What does that mean?
- Is it limited to data center SDN overlays (as ECOMP SDN-C is today)?
- Are you considering WAN connections? How about underlays? Are they in scope here, or are you envisioning someone would start a separate project in the future to address these items?
Multi VIM/Cloud (5/11/17)
(Stephen)
- Scope: It would be good to be clear on the modules this produces and APIs it defines. It feels like it is a new module (as one can read the infra controller as being openstack, and this seems to sit in between).
- Related: This has an impact on SO and controllers as they assume openstack today. This will be a new interface to be defined (by this project I assume) that needs to be implemented by SO,VF-C, APP-C. Is this handshaken with them (comments suggest this is the case, but its not clear to me).
- Scope: Closed loop remediation: Would be good to be clear on the relationship with DCAE here. Is this to deliver a module to be used by DCAE, or should that part be part of DCAE? Keep in mind that the module relates to a repo that has a set of committers
Scope: "should align with common controller framework" - any chance to be more specific as to what is being considered here.
(Lingli Deng)
- Need more specific scope clarification on dependency/impact to DCAE in how FCAPS data would be collected and abstracted via multi-cloud and fed into DCAE in a infrastructure-agnostic manner to address the usecase requirement for cross-layer fault correlation.
(CJD) I'm confused about the closed loop remediation, as well.
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.
(CJD)
- All participants are listed as committers (34). Please review and decide who is a committer and who is a contributor.
ONAP Operations Manager (5/10/17)
(Stephen)
- I was unsure whether this is two projects or one (ONAP operations manager and ONAP operations manager / ONAP on containers). I am not sure how to differentiate the deliverables from the projects.
- While it may be obvious, it would be good to call out the modules being produced
- Does the project feel that there are APIs that it is responsible for?
- The committer list is rather long, 1-2 per company?
(Jason Hunt)
- Good proposal. This is an important project to help with the consumability of ONAP across users as well as ensuring efficiency of the overall ONAP development process. You might want to list projects that would benefit from ONAP Operations Manager, such as the virtual and physical lab projects.
- There is overlap with the Microservices Bus proposal in the health checking of components and service registry. There should be a single project that can check the health of not only the VM/container but the running microservice as well. I highly recommend leveraging existing open source projects that will do this health checking and registry for you. Possibilities include: Consul, Eureka, Marathon's service discovery, or Kubernetes service routing… or the recently announce istio (from Google, IBM, and Lyft).
- For the components within ONAP Operations Manager, is there a possibility to leverage other ONAP components to do this? For example, the UI component should be accessible from the main ONAP portal. Understand that there may be a bit of a bootstrapping issue, of course.
- For the following portion of the project description, you might want to clarify that this is only for control loop actions on the ONAP components themselves, not the VNFs: “monitor actions that have been taken as part of a control loop (e.g., scale in-out, self-heal)”
(CJD)
- Would you please clarify your resources list? Who is a committer and who is a contributor?
Testing & Certification
(CJD) General comment for the three related projects (VNF Requirements, VNF SDK, and ICE): These projects are closely related, and we worked to align the scopes. The committers for each of the projects are different, which is one of the main reasons we made the split where we did. VNF Requirements is creating requirements for VNF vendors (documentation), VNF SDK is producing tools (code), and ICE is producing the validation testing program (governance, etc.). The skillsets are different.
VNF Guidelines (Renamed as VNF Requirements)
(Lingli Deng)
I suppose it is now renamed as VNF Requirements, and hence the following comments goes to the proposal at: https://lf-onap.atlassian.net/wiki/display/DW/VNF+Requirements
- 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.
- (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.
(Lingli Deng)
- +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 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?
(Ranny Haiby)
- It would be good to limit the scope of the VNF functional validation/tests. This in itself is a potential for a whole new project and community. A narrow definition of the validation such as "basic functionality" or "smoke test" would probably serve this project better.
(Lingli Deng)
- Need more clarification on the potential overlap with tooling from ICE for VNF validatation and testing.
(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.
Integration (5/11/2017)
Reference VNFs Project (now part of the Integration Project)Analysis
(Roberto kung)
we need to clarify how it works with OPNFV CI/CD or PF (should be easy as some actors Huawei/Orange/ATT … are in both). May be a big project (but it builds on OPEN-O experience, and on what will be brought by OpenLab)
Helen Chen: We are trying to leverage OPNFV lab space for ONAP R1 CI/CD testing, especially from developer point of view. In the longer term, we are looking for a more harmonic way to collaborate with them.
I agree that this project is big, but all aspects are tightly related. We have subgroup who are responsible and focusing on each category, and collaborate with the rest of Integration team.
(Ranny Haiby)
- It is not immediately clear from the project definitions what types of labs will be required. It is implied by the first diagram, and also discussed by Catherine in some email threads. Perhaps it would be best to explicitly describe what types of labs will be required by the integration project.
Helen Chen] Please refer to this doc: Test requirement from developer point of view
(Mazin Gilbert)
- 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)
One key principle is to have ONAP compliant VNF with VES agent (as implied by the use of DCAE). To clearly stated in VNF guidelines. In rel 1, data collection adaptors to fit R1 usecases. NB: intel proposed to commit on NFVI data collection adaptor, not mentioned here.
The VolTE use case includes the End to End automation subcase, and the DCAE should also be able to have netconfPNF collector such as SNMP: it opens Onap to PNFs. In particular, it is important to focus on SBI (southbound interfaces) and Data Models (see contrib attached) and to clarify the interaction with SDNC. Also for SNMP (to collect traps) SNMPv3 would be more secure than SNMPV2c. But in general, telemetry with PULL (network state subscription) to be used (SNMP, netconf are PUSH). We also need to clarify that Volte usecase include EPC and end to end automation.
AI/ML could be lower priority (of course important in future) for R1.
Storage: it could be possible to use external DB may be lower priority
We need to work more on scalability requirements for real production of a big EPC/IMS/Volte.
cloud computing… collection and analytics”: the cloud infra provider may be impacted as it sends some events to DCAE. These events should be defined (failure, what type of failures…).
What is the role of cloudify? (what part is meant to be used, is it related to the TOSCA parser?)
(Stephen)
- This is 3 subprojects. Be clear on the committers on the scope
- The “Demo repo” is unclear to me what that is about, that could be in the scope of the Use cases project (Please sync with use case project on this)
- There is a question about the handling of VES That comes externally, I am not sure of what is best, maybe Ed or someone can advise.
- It should be clearer which interfaces the project feels it is responsible for defining, and which it uses. It would be good if this was defined on the per-subproject basis.
- “dependency to other OS projects”: For VES, shouldn’t it list OPNFV?
- As this project now incorporates parts of Holmes (which I think is a good idea), does the seed code also include the seed code listed in the holmes project?
(Lingli Deng)
- We might want a portal for DCAE to enable the user to have a systematic view of the information gathered. For example, considering the requirement for performance monitory, we need a UI interface to ops rep to monitor the performance stats.
Holmes (5/11/17)-
(Roberto Kung)
Holmes should be looked with Clamp or/and Policy, mainly policy (with introduction of engines and so on). May be a split is needed (analytics – alarm aggregation, filtering, correlation in DCAE analytics microservices / policy design RCA in policy). May not be high priority for R1 (not needed for our use cases). But it is useful to show intents for following releases
(Lingli Deng)
Just to clarify, cross-layer fault correlation is in scope for VoLTE usecase for auto-healing.
(Mazin Gilbert)
- This project should be split and combine with DCAE (for the correlation engine), Policy engine (for Drools), and CLAMP (for designing the open loop).
- (Lingli Deng) What about the portal demonstrating the alarms gathered, and correleation made? Would DCAE be providing a portal for that?
Common Platform & Utilities
ONAP Extensibility (5/16/17)
(Zhaoxing)
(Alla)
Should be part of common platform umbrella project.
(Xinhui li)
This project targets to resolve an important problem in ONAP development and need cooperation with almost all projects. Need to define process/methodology/checkpoints to form and enforce the recommended patterns.
Authentication and Authorization Framework (5/16/17)
(Zhaoxing)
Could the project proposal clarify how to enforce the auth of asyn message publishing/subscription and the sync REST requests separately?
Will this project enforce access control between the components inside the ONAP system, for example, the communication between SO and A&AI?
Will this project implement centralized auth for all the ONAP components, or user need to log into every component? If that's the expectation, AAF may need to discuss with MSB team about the possibility of the AAF MSB integration approach for centralized auth, which is listed in the MSB use cases.
Is there any internal or external dependencies for this project?
No enough participant companies, according to the proposal framework, a proposal should have at least 3-4 companies involved to provide diversity
Lack of link to seed code
(Alla)
Should be part of common platform umbrella project
(Xinhui Li)
Need to consider authentication federation with other parts like underlying OpenStack Cloud. Better if more company diversity.
Microservices Bus(5/12/17)
(Zhaoxing)
(Alla)
Should be part of common platform umbrella project
(Jason Hunt)
- There is overlap with the ONAP Operations Manager proposal in the health checking of components and service registry. There should be a single project that can check the health of not only the VM/container but the running microservice as well. I highly recommend leveraging existing open source projects that will do this health checking and registry for you. Possibilities include: Consul, Eureka, Marathon's service discovery, or Kubernetes service routing… or the recently announce istio (from Google, IBM, and Lyft)
(Xinhui li)
Clarifify the call flow with other related projects will help the overall design.
Common Controller Framework (5/12/17)
(Zhaoxing)
I would suggest renaming this project to Common Controller SDK because it provides building blocks for controllers.
Will this project provide source codes or binaries(libs) for controller projects?
Could this project proposal clarify what exactly is "Common microservice / VF lifecycle management"? It seems conflict with OOM and SO/VF-C/APP-C.
Could this project proposal clarify what exactly is "Common model management"? It seems to conflict with modeling project.
Lack of link to seed code
(Alla)
Should be part of common platform umbrella project
(Stephen)
- (Related to comment from Alla: I don't understand the intention of this to be under the common platform, but more a SDK or set of components for the controllers).
- Scope: It would be good to coordinate with the other controller projects to decide on which APIs this project is responsible for defining, vs providing/using.
- Dependencies: are there dependencies on the platform?
- Scope: Question (not a statement): Is the SLI and Tosca parser part of this or separate (e.g. in modeling?).
- I think we should see the handshake with the controllers on which parts they plan to take/when to ensure that there is a focus on what is prioritized.
- Committers - suggest 1-2 per company
(Alla)
Related to comment from Stephen. I see CCF as a part of either Common platform/Utilities or Common Controllers umbrella projects. regarding Common platform/Utilities, the common thing is that the code created by this project would be utilized be a different modules in order to support the same functionality of a different modules.
The other way looking on it is to unify it with the "Controllers" umbrella project, if we had such, however to me it doesn't look like it makes sense to create such an umbrella (i.e. I believe, for instance, that APPC, SDN-C etc. should run as a separate projects).
(Xinhui Li)
This project seems to want to resolve code reuse problem among all the controllers. Need more clarification on the concrete scope. High level terms are listed in the scope section like Common health checks. Need to provide more fine-granularity design for more understanding of overlap with others. The list of dependencies with other open source projects need more explanation too.
DMaaP – Data movement as a platform (5/16/17)
(Zhaoxing)
(Alla)
Should be part of common platform umbrella project
(Xinhui Li)
This project targets to provide data filtering/processing/transportation support by leverage other open sources. With the big scope, the team need to clarify what is the focus in R1. Also need seed code list and company diversity.
Modeling & Design
Note on this section:
The part under the names is comments received from the individuals.
Where it says "review comments" is the consolidated comments after discussion, following the criteria/skeleton proposed.
Modeling (5/11/17)
Review:
Clarity of Scope:
Reasonable and Well defined Scope:
- 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?
Identification of SW modules and APIs being developed and delivered to other components
- 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. consider separating tooling from models in repos as the code will be pulled down separately from the tools.
- Be clear on the tools to be as a deliverable, and the APIs. e.g. a model passer
Follow project and LF guidelines for contributors/committers:
- The number of committers is very high, perhaps 1-2 per company
Identification of dependences and assumptions on other components and open source
Overlap
Intentional and unintentional overlap
- In general, what does the existence of data model and information model mean? That they must be used by all other projects? Could be used? (i.e. is this producing models that the other projects must use, or this a coordination activity providing guidance)
The suggestion here is where it states: Deliverables for R1, state which projects depend on this and handshake with them also the timing.
overlap with external opensource efforts
Risk Management
Sufficient resources allocated to deliver on time:
- Yes there are sufficient resources, the risk is the discussion on this interesting topic could delay other dependent projects, so important to handshake the needed timing.
At least 3-4 companies involved to provide diversity:
Available seed code and maturity
Relevance and prioritization
Alignment with merger release
Alignment with use cases
Sound technical solution solving a real need.
(Xiaojun)
- 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 .
(Ranny Haiby)
- 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.
- 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?
- In general, what does the existence of data model and information model mean? That they must be used by all other projects? Could be used?
(i.e. is this producing models that the other projects must use, or this a coordination activity providing guidance).
(Review meeting)
- On the R1, please state which projects will use which models. We want to know how the projects are going to interact with the projects and whether they expect to receive the model or receive coordination and guidance.
CLAMP (5/11/17)
Review Comments:
Clarity of Scope:
Reasonable and Well defined Scope:
- Could the proposal clarify the functionality implemented by the control loops? And what’s the relationship with Holmes?
- Editorial: Commetters and contributors are listed twice
- A high level workflow showing the CLAMP part and the relationship with the other components would help to clarify.
- needs analytics microservice description to be included in its design capabilities
Identification of SW modules and APIs being developed and delivered to other components
- Can it be clarified what the deliverable is in terms of deliverables: Code modules, templates, .... I understand the concept, but I am trying to figure out what is delivered by this project compared to SDC, and modeling
- Dependant interfaces are identified. The assumption is that this project does not define interfaces.
Follow project and LF guidelines for contributors/committers
- In general yes, though increased diverstity of the committers would be appreciated.
Identification of dependences and assumptions on other components and open source
Overlap
Intentional and unintentional overlap
- Scope: Regarding E2E call flows, alignment with the architecture team on the scope would be good.
- Can parts of Policy driven VNF orchestration be incorporated? (and coordinate with project)
- It would be good to clarify the relationship with SNIRO (and coordinate with project)
- Look at Holmes scope to see if some is relevant here (and coordinate with project)
overlap with external opensource efforts
Risk Management
Sufficient resources allocated to deliver on time:
At least 3-4 companies involved to provide diversity:
- No, increased diversity is encouraged
Available seed code and maturity
Relevance and prioritization
Alignment with merger release
Alignment with use cases
Sound technical solution solving a real need.
(Xiaojun)
(Stephen)
- Scope: Regarding E2E call flows, alignment with the architecture team on the scope would be good.
- Editorial: Commetters and contributors are listed twice.
- Can it be clarified what the deliverable is in terms of deliverables: Code modules, templates, .... I understand the concept, but I am trying to figure out what is delivered by this project compared to SDC, and modeling.
- Can parts of Policy driven VNF orchestration be incorporated?
- It would be good to clarify the relationship with SNIRO.
- Look at Holmes scope to see if some is relevant here.
- A high level flow (technical) showing the CLAMP parts and the interaction with the other projects would be great.
(Roberto)
(mazin)
Overlap with Holmes. Have that project intgerate with CLAMP.
(Zhaoxing)
From my understanding, the main goal of CLAMP should be:
Design time:
Design close loops to connect the models and actions distributed in different components together, such as metrics definition in VNF model, data collection ? analytics in DCAE, policy and vnf/ns lifecycle management in SO/VF-C/APP-C.
(Eden Rozin): Design close loops is part of the DCAE-D (i.e. DCAE Designer) module which is part of SDC; Close Loops (CLs) are attached to the Design Object (e.g. VNF, Services) and distributed to runtime components (DCAE).
Run time:
Present the status of the running close loops.
However, from the description of the proposal, it seems that DCAE is responsible for the execution of close loop, I might be wrong at this, but it would be great if a high-level workflow diagram could be used to clarify how close loop is designed and enforced, as well as the interactions between the involved components such as SDC, DCAE, Policy, SO/VF-C/APP-C, etc.
Below is extracted from project proposal
Interfaces:
The following interfaces will be implemented by other components but used for CLAMP. Therefore, CLAMP has these as dependencies:
Query and update services in SDC
Query and update control loop templates in SDC (future not in R1)
Policy interfaces for creating/updating configuration and operational policies
DCAE interfaces for deploying/undeploying control loops
Runtime messaging interface between DCAE and Policy
Service Design & Creation (5/17/17)
Review summary:
Clarity of Scope:
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
Overlap
Intentional and unintentional overlap
- Any relation to ICE?
(Eden Rozin): Process wise; when a VNF is 'Certified' according to standards, thus it passed ICE, in can be onboarded to SDC for further enrichments as a reusable Asset in Catalog; this process-wise handshake can be automated.
overlap with external opensource efforts
Risk Management
Sufficient resources allocated to deliver on time: Yes
At least 3-4 companies involved to provide diversity: Yes
Available seed code and maturity: Yes
Relevance and prioritization
Alignment with merger release: Yes
Alignment with use cases: could be clarified better.
Sound technical solution solving a real need: Yes
(Xiaojun)
Could the proposal describe the scope of the catalog module?
(Eden Rozin): The catalog hold all Design Assets as a reusable building block for Design; it holds: VNFC, VNF, Service, Polices, Monitoring Templates (Close Loops, Open Loops), Orchestration Workflows, APIs and Artifacts.
(Alla, Andrei)
- SDC should be an umbrella for all Design time parts from other Projects (CLAM, Policy, Converged ICE & VNF SD-K);
(Eden Rozin): Agree.
- SDC is a platform for all the modeling and design in ONAP and provides the interactive tool for design and automation for on-boarding.
(Eden Rozin): Agree.
(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?
(Eden Rozin): Answered in a previous comment.
Active and Available Inventory (AAI) (5/11/17)
Review Comments:
Clarity of Scope:
Reasonable and Well defined Scope:
- quite ok, except for the deliverables.
- Editorial: refers to MSO, should be SO.
Identification of SW modules and APIs being developed and delivered to other components
- No, this could be clearer
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
Overlap
Intentional and unintentional overlap
overlap with external opensource efforts
-ok, no
Risk Management
Sufficient resources allocated to deliver on time:
At least 3-4 companies involved to provide diversity:
Available seed code and maturity
-ok, yes
Relevance and prioritization
Alignment with merger release
Alignment with use cases
- appears so, but use cases not mentioned.
Sound technical solution solving a real need.
(Stephen)
- In this scope it would be great to be clear on the modules that are to be delivered in general.
- In the scope it would be great to clarify whether this project responsible for any APIs to be defined, I assume so.
- Perpahs 1-2 committers per company?
- Editorial. Referens to MSO, should be SO now.
Network Function Change Management Project Proposal (5/11/17)
Review Comments:
Clarity of Scope:
Reasonable and Well defined Scope:
- it was unclear what this was to deliver, requirements or code.... Then, if there was code whether that was overlapping with other projects...
Identification of SW modules and APIs being developed and delivered to other components:
- It would be great to be clear on the code module deliverables from this project so we can understand whether there are overlaps in the deliverables with the other projects (e.g. SDC). i.e. what is planned to go into the repo NFCM. i.e. from the scope of this, it feels like it should be part of SDC or produces requirements, however I would like to understand the deliverables to get a clearer understanding of that
Follow project and LF guidelines for contributors/committers
- no, further diversity would be appreciated.
Identification of dependences and assumptions on other components and open source
Overlap
Intentional and unintentional overlap
- This can be clarified when the modules are clarified. Keep in mind that the code can only go into one repo
overlap with external opensource efforts
Risk Management
Sufficient resources allocated to deliver on time:
At least 3-4 companies involved to provide diversity:
-no, one company
Available seed code and maturity
- indicates, that there is.
Relevance and prioritization
Alignment with merger release
Alignment with use cases
- Independent, i.e. could release with or without deliverable
Sound technical solution solving a real need.
(Stephen)
- It would be great to be clear on the code module deliverables from this project so we can understand whether there are overlaps in the deliverables with the other projects (e.g. SDC). i.e. what is planned to go into the repo NFCM. i.e. from the scope of this, it feels like it should be part of SDC or produces requirements, however I would like to understand the deliverables to get a clearer understanding of that.
External API Framework (5/15/17)
Review Comments:
Clarity of Scope:
Reasonable and Well defined Scope:
- mainly ok
- modules to be delivered could be clearer.
- On the models, discussion with the modeling project about what are the models covered in this project vs the modeling project would be great. I can see what the line would be though. the TMF SID maybe one point to align on (not clear how that would be part of integration)
- Not sure what TMF SID is doing here, relation to model project ......
Identification of SW modules and APIs being developed and delivered to other components
Follow project and LF guidelines for contributors/committers
Identification of dependences and assumptions on other components and open source
Overlap
Intentional and unintentional overlap
- potentially with models on model driven interface, just needs to be clarified.
- TMF SID? with modelling
overlap with external opensource efforts
Risk Management
Sufficient resources allocated to deliver on time:
At least 3-4 companies involved to provide diversity:
Available seed code and maturity
- No information, could be stated if there is.
Relevance and prioritization
Alignment with merger release
- independent, necessary area but release could happen with/without
Alignment with use cases
Sound technical solution solving a real need.
(Stephen)
- Scope: Question: Does this provide a SB API definition into ONAP (or use one) and a "plug-in" environment for bringing the external interfaces?
- Scope: Clarify the code modules that are a deliverable.
- Scope: On the models, discussion with the modeling project about what are the models covered in this project vs the modeling project would be great. I can see what the line would be though. the TMF SID maybe one point to align on (not clear how that would be part of integration)
External System Register (5/14/17)
Review Comments:
Clarity of Scope:
Reasonable and Well defined Scope:
- Could be clearer, exemplify with a use case.
Identification of SW modules and APIs being developed and delivered to other components
Follow project and LF guidelines for contributors/committers
Identification of dependences and assumptions on other components and open source
Overlap
Intentional and unintentional overlap
overlap with external opensource efforts
Risk Management
Sufficient resources allocated to deliver on time:
At least 3-4 companies involved to provide diversity:
Available seed code and maturity
Relevance and prioritization
Alignment with merger release
Alignment with use cases
Sound technical solution solving a real need.
(Stephen)
- Scope: could be a little clearer by way of example..
Policy
Policy Framework Project Proposal (5/11/17)
(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
- 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).
(Ranny Haiby)
- It might be cleaner to keep all references to Release 1 in the release plan.
- Could the outcome of the classification process also include guidelines to ONAP developers on when the policy framework should be used (and when not)
- Could you please clarify the scope? Is a Policy Decision Engine one of the deliverable? Is there one central instance of the engine for the entire ONAP or could each module have its own? If central, how do you determine which technology to use?
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.
(CJD)
- Alex mentioned that this is a sub-project of Policy Framework, and should not be evaluated on its own.
- I am not entirely clear on the artifacts from this project.
- Are they covered by SNIRO?
- Are they requirements for other projects to implement? If so, perhaps a coordinator or subcommittee might be appropriate?
(Lingli Deng)
- It is not clear how a controller/orchestrator would do to implement the PEP.
- It is more like a placement optimization application scenario rather than related directly to policy or policy framework.
(Jason Hunt)
Placement of VNFs onto optimized hardware is a key requirement. The question is how to implement it in the scope of the other project proposals. It seems to me that policies for placement could be defined within the policy engine (driven by the Policy Framework proposal), but that it is up to the orchestrator and multi-VIM (or even the VIM’s themselves) to enforce those policies for placement. Likewise, the SNIRO project also covers this area of placement/homing. We need a consistent approach for how to define placement policies/constraints. I suggest this team consult with the SNIRO team on an approach and work with the orchestration and multi-VIM projects on how to link in policy/optimization for placement.
(Lingli Deng)
- +1 to consider openning up to committers from other companies, to encourage participation and contribution where there is clearly specified commitment for Release 1.
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.
(CJD)
- Would you please differentiate between committers and contributors?
(Jason Hunt)
- This is a well written project proposal with important scope for a mature ONAP implementation.
- The scope is quite aggressive. Can you clarify what scope will be provided in the seed code and what scope is anticipated for delivery in R1?
- Have you communicated with the project leads for your project dependencies? For example, Service Orchestrator or Multi-VIM needing to call to SNIRO for a homing solution.
- The scope item #7 references ONAP-Controller, which is not a current project proposal. Should this be the ONAP Operations Manager?
UI & Portals
Portal Platform Project Proposal (5/12/17)
1. Clarity
a. Reasonable and well defined scope
It is reasonable to have a common portal framework for various UIs from different backend functional modules of the system. But it is not well specified in the project proposal. In particular, in the scope section, it describes the portal, not the portal framework, which is confusing. Suggest to refine the description in accordance with the proposed portal architecture and clarify its scope in relation with other functional modules or portal pages, in more detail. And identify extra functionality or APIs to be implemented during Release 1, if any. To be more clear on the APIs that project feels it is defining.
b. Identification of software modules and APIs being developed and delivered to ONAP and other components.
No. There is not statement but an architectural diagram for software modules to be delivered.
c. Following project and LF guidelines for contributors/committers
Only 4 people from one company committed.
d. Identification of dependencies and assumptions on other components and open source.
Yes. Dependencies with other open source projects, are identified.
2. Overlap
a. Intentional and unintentional overlap
No overlap with other projects identified, assuming the scope is the portal framework, not the portal.
b. Overlap with external open source efforts
N/A.
3. Risk management
a. Sufficient development resources allocated to deliver on time
There is little resources allocated/committed. Only 4 people from one company involved. But since there is no explicit requirements for development identified for the first release. The work seems only involving maintenance and support.
b. At least 3-4 companies involved to provide diversity
Only 4 people from one companies involved. Encourage the project to also look for committer from another company.
c. Availability of seed code and its maturity
It is supposed to be based on the existing openECOMP portal framework code base.
4. Relevance and prioritization
a. Alignment with merger release
Yes.
b. Alignment with use cases
N/A. It is a common portal framework, which is supposed to be the basis for use case specific portal development.
c. Sound technical solution for solving a real need
Yes. The seed code is mature and deployed for years of practice.
ONAP Usecase UI Project Proposal (5/15/17)
1. Clarity
a. Reasonable and well defined scope
It is reasonable to have UI developed for usecases if the requirements are not met by the existing platform portal. It may be a good idea to have the project include a long-lived project scope while leaving the specific use cases to the R1 release plan. For both use cases - Recommend defining the persona using the UI (is it self service? is it used by some care center? sales center? etc. For the VoLTE use case - What is the business use case here? Who is the target end customer? Is it an enterprise customer of the CSP? Is it an internal customer inside the CSP? For both use cases, what is the required functionality? Service deployment? Maintenance? Performance monitoring? Troubleshooting?
b. Identification of software modules and APIs being developed and delivered to ONAP and other components.
Need more clarification on the software modules and APIs to be delivered. Should be following the proposal template.
c. Following project and LF guidelines for contributors/committers
Yes. 4 people from 3 companies involved with clear responsibility.
d. Identification of dependencies and assumptions on other components and open source.
Need to clarify the scenarios, and dependencies with other components.
2. Overlap
a. Intentional and unintentional overlap [Lingli] No overlap with other projects identified, assuming the scope is the portal framework, not the portal.
b. Overlap with external open source efforts [Lingli] N/A.
3. Risk management
a. Sufficient development resources allocated to deliver on time
Yes.
b. At least 3-4 companies involved to provide diversity
Yes.
c. Availability of seed code and its maturity
Not clear.
4. Relevance and prioritization
a. Alignment with merger release
Yes.
b. Alignment with use cases
Yes.
c. Sound technical solution for solving a real need
Note clear.
VID project (5/17/17)
1. Clarity
a. Reasonable and well defined scope
Not clear whether or not VID would include a portal, and its separation of responsibility for usecase UI requirements and scenarios.
(Eden Rozin): VID will include a portal for Operations to invoke Instantiation of Services and VNFs and to perform Maintanence (Change Management) activities.
b. Identification of software modules and APIs being developed and delivered to ONAP and other components.
Yes. Suggest to change MSO into SO.
c. Following project and LF guidelines for contributors/committers
Single company involved. inconsistency with the information sections, including primary contact, leads, etc.
d. Identification of dependencies and assumptions on other components and open source.
Yes. Change MSO into SO.
2. Overlap
a. Intentional and unintentional overlap
Potential overlap with usecase UI for service/VNF LCM management UI,if it include a portal itself.
b. Overlap with external open source efforts
N/A.
3. Risk management
a. Sufficient development resources allocated to deliver on time
Yes.
b. At least 3-4 companies involved to provide diversity
No, only a single companies involved. Encourage other members to join for substantial development work or consider merger.
c. Availability of seed code and its maturity
Yes, seed code available.
4. Relevance and prioritization
a. Alignment with merger release: Yes.
b. Alignment with use cases: Yes.
c. Sound technical solution for solving a real need: Not clear, as no technical solution is described.
ONAP CLI
(Lingli Deng) From the list discussion, I was under the impression that the authors of this proposal decided to postpone it for future releases.
Documentation & Training
Documentation (5/11/17)
1. Clarity
a. Reasonable and well defined scope
Scope is reasonable and follow the common practice of open source projects. However, the deliverables is not yet well specified. And the seed code section points only to the openECOMP documentation, which might be confusing.
Will this project be responsible for the documentation? Suggest to clarify the deliverables and clarify the scope of responsibilities and how to enable collaboration between projects/sub-committees that produce documentation and this project. Examples include: architecture from the Architecture Sub-Committee, models from Modeling project, use cases from potentially the Usecase Sub-Committee, etc.
Will this project be responsible for the automatic documentation tooling? Suggest to clarify the scope of responsibilities and how to enable collaboration between the projects that produce tooling and this project. Examples include: integration, common platform services, etc.
b. Identification of software modules and APIs being developed and delivered to ONAP and other components.
This project does not provide any software modules or APIs. But depending on its clarified scope, it might provide tooling for documentation, which might overlap with integration.
c. Following project and LF guidelines for contributors/committers
Yes.
d. Identification of dependencies and assumptions on other components and open source.
Yes.
2. Overlap
a. Intentional and unintentional overlap
Might be intentional/unintentional overlap with integration, architecture, usecase, modeling and other projects that provide (tooling for) documentation.
b. Overlap with external open source efforts
N/A.
3. Risk management
a. Sufficient development resources allocated to deliver on time
Documentation, by definition, depends on other projects to provide source material.
b. At least 3-4 companies involved to provide diversity
There are five companies involved already.
c. Availability of seed code and its maturity
Seed documentation provided from openECOMP, need to be revised and keep consistent with the code as it evolves.
4. Relevance and prioritization
a. Alignment with merger release
Yes.
b. Alignment with use cases
Not specified explicitly. But committers are added to explicitly address the end user/use case perspective.
c. Sound technical solution for solving a real need
Yes. The team is evaluating the use of readthedocs.org as way of publishing documents, and the use of swagger.io for API documentation. Need to work closely with the release manager in planning deliverables and tooling provision in time.
ONAP University (5/11/17)
1. Clarity
a. Reasonable and well defined scope
It is important for a complicated open source software to provide training material to end users as well as developers to attract more participation and adoption.
However, the scope description can be more clear and distinctive from what is already stated in documentation project proposal, perhaps in terms of the form of deliverables, the people involved, etc.
It is clear that marketing committee will be involved heavily in training program, which makes it important to understand why we need a separate technical project rather than a sub-committee led by Marketing Committee for training, in addition to documentation.
b. Identification of software modules and APIs being developed and delivered to ONAP and other components.
This project does not provide any software modules or APIs.
c. Following project and LF guidelines for contributors/committers
It is not very clear how this project will be working with the Marketing Committee in training activities, or how this project will be working with the other projects, especially documentation project, in producing/providing overview for consistent training material.
d. Identification of dependencies and assumptions on other components and open source.
Yes. Dependencies with all projects (including the Marketing Committee) to provide training, is identified. Need further clarification on the relation with documentation, if possible.
2. Overlap
a. Intentional and unintentional overlap
Might be intentional/unintentional overlap with documentation and Marketing Committee.
b. Overlap with external open source efforts
N/A.
3. Risk management
a. Sufficient development resources allocated to deliver on time
There is little resources allocated/committed to finish the scope alone. Need more clarifications or more involvement with the Marketing Committee or documentation.
In particular, various forms of trainings are suggested, including Video/Online/Classroom/Hands-on/Blog/Webinar, but no specific deliverable/budget planning involved, need Marketing Committee guidance and commitment in the planning and practice.
b. At least 3-4 companies involved to provide diversity
4 people from 4 companies committed.
c. Availability of seed code and its maturity
N/A.
4. Relevance and prioritization
a. Alignment with merger release
Yes.
b. Alignment with use cases
Not specified explicitly. But committers are added to explicitly address the end user perspective.
c. Sound technical solution for solving a real need
Yes. Various forms of trainings are suggested, including Video/Online/Classroom/Hands-on/Blog/Webinar, but no specific deliverable/budget planning involved, need Marketing Committee guidance and commitment in the planning and practice.
Misc.
Open Lab (5/23/17)
Agreed to postphone it for further formal project proposal.
VNF Requirements
Grouped under the category of "Testing and Certification" category above.