...
| Time | Item | Who | Notes |
|---|---|---|---|
| Discussion on functional features that are applicable across use cases (Alex Vul) | |||
| Discussion on fetching policies (EMF vs TOSCA) and whether SDC GUI will show the models. Ramki: strongly recommend Tosca. | |||
| What to do if ONAP and ECOMP-SO are differences? | |||
| Discussion on A&AI interface – some functionality we want may need agreement from A&AI team | |||
| Identification of port numbers (see notes below) |
Action items
- Create a JIRA for Developer Page (Dileep to create and assign to Sastry for now)
- CLM – Sastry to follow up
- Jenkins Merge Job for OSDF – Sastry to follow up
- Meeting with Seshu/Cory on OOF-SO API changes (Matti/Ankit)
- Alex to review functionality that is required for multiple use case (focus on R3 needs) – we can probably do it as needed
- Functional testing needs: Everyone should review the test cases (provide feeback; at a minimum be aware of the scope and functionality)
- Develop a scrum stand-up meeting template – get an OK from the team
- Identify contributors committed for R2 release (OK to start with small list and add)
- Create jira's for model-driven optimization modules (minizinc dockerization and linking to OSDF) – simple unit tests and example CM app (Ramki)
- Create jira's for MSB and API (Ankit)
- Interaction wirh policy team to finalize policy modeling language (TOSCA vs EMF) and also the variant (DCAE vs next-gen) – has to be TOSCA sooner than later
- Create a requirement for Policy team (so they will either blanket support for ONAP or not)
- Extreme case, use DCAE model structure (TOSCA, but is a variant)
...
- A PhD student that has worked on Minizinc models for Software-defined Constrained Optimal Routing Platform for SDN (article link). Link for slides is here.
- Arun Arora from VMWare will participate in end-to-end integration work (MC, OOF, etc., from vCPE perspective)
- Ramki's question on port numbers: are they fixed (yes), do we want to keep them so (maybe):
- As an example, OSDF has 14699 and we don't want it to be so.
- With K8S, we do not even need to specify ports (via proxies). However, how would we reconcile with that?
- Decide on which processes go inside K8S pods
- A container specifies a port to bind to (inside a pod or container). K8S will provide a proxy for other components to connect to this container. So, modules can have their own ports without ever exposing them and only expose via proxies. Only need to ensure that no collisions occur within a pod.
- Older code base was on a "large docker host" and multiple applications had to be on same IP, hence port numbers like 14699.
- Conclusion: we can keep weird port numbers, and can use proxies, and one does not interfere with another