Recording: 20200717 CNF Weekly Meeting.mp4
Pending Initial Tasks (REQ 394 Needs Prioritization into a Release and Contributors assigned to its items) Beyond Guilin Timeframe
1.Describe the Information Element in words
-Please provide any relevant references, such as other standards, etc.
2.Define the properties (e.g., attributes, known relationships, etc.)
3.Where does this information come from? (i.e. originator)
4.Who uses this information inside & outside of ONAP? (i.e. consumers)
-How do they use it?
5.Who updates this information inside & outside of ONAP? (i.e. producers)
6.Where will this information stored and maintained in ONAP? (i.e. steward)
7.Perform UML Modeling (including mapping to existing concepts)
8.Prioritization for ONAP Releases
9.Identify impacted ONAP schemas & APIs
-Are there existing schemas be used or extended?
10.Develop implementation schema (identify component impacts on schema changes)
Project tickets for modeling effort:
AAI-2929 - Getting issue details... STATUS
Information Elements
We need to understand which are the key elements ONAP needs to be aware of. Those should be driven from the use case flows.
This Week's Agenda:
Use Cases and Assumptions - Amir Caduri(Amdocs) - Healthcheck and post-instantiation will be the two use cases to start from
Eric Multanen has an action item for this week to provide some example of the status/resource object from the k8s plugin.
Next Week's Agenda:
Lukasz Rajewskiwill discuss the health check use case broken down into more details
Milind Jalwadi to share some details on the work he has been doing
Attendees:
@Marian Darula
@Ram Rana
| Topic | Contributors | Comments |
|---|---|---|
| Use Cases | Amir Caduri | Continuation from the last meeting, Amir's deck was shared on the use cases Question arose on whether a cloud-region is 1:1 with cluster? Meaning is a cloud-region = cluster |
| K8s Plugin status/resource | Eric Multanen | Shared a deck about the status/resource object from the k8s plugin Discussion came about on what to store in AAI, higher level information to query extra info from kubernetes APIs, or more robust. Most participants agreed higher level information should be stored and used to make subsequent kubernetes calls is the way to go. |