...
07/12/17 - APPC Project Weekly Minutes
Agenda:
- ODL Version for R1
- vCPE Use Case
- Code Contributions
- Labs for testing
- MultiVIM
- OOM
- Integration Testing with AAI & SDC
- Other topics?
Notes:
- ODL Version for R1
- Confirmed with SDNC team - they will be using Carbon release of ODL for R1.
- ODL Docker will not be available until end of July.
- SDNC-26 (ODL upgrade) - ETA is end of July
- APPC Story needed: Need story to upgrade ODL version to Carbon
- vCPE Use Case
- https://wiki.onap.org/pages/viewpage.action?pageId=3246168
- Confirmed that we are part of close loop, triggered by Policy
- APPC action will be Restart of vMUX
- VNF restart (dependency on DG code contribution from AT&T, ETA pending), VNF restart will entail AAI query for needed data
- Code Contributions -
- Upcoming code contribution from AT&T pre-requisite for vCPE use case support, teams working to get that submitted
- awaiting ETA (restart DG key)
- Action: Follow-up with Scott on the list of DGs being open-sourced
- Labs
- T-Lab: Lab prep in progress - Spondon working on this - availability date TBD
- T-lab still waiting on servers… not likely to be ready this week
- T-Lab lab will be available externally via VPN
- Integration team discussion with WindRiver for a possible development lab for pairwise testing… more details pending.
- They are taking images from Jenkins (latest image) to stand up lab…..
- Generating jira issues if they run into problems
- Focusing on e2e connectivity at the moment, using the demo use cases to validate lab.
- MultiVIM
- Scope for R1 - MultiVIM proxies requests…
- Need to confirm support for R1 from CDP-PAL development team
- CDP-PAL is not part of ONAP and opensource available via github, so we need their agreement to partner on this release for any changes needed in CDP-PAL.
- Reached out to development owner of CDP-PAL (Ram Koya), awaiting feedback from the team if they have capacity to support.
- Assuming CDP-PAL is onboard, when would MultVIM target for readiness to start integration testing.
- Action: Randa to check if there are any dependencies between Carbon & CDP-PAL - checking with Varun
- Multivim: R1 is a short term goal to demonstrate integration with APPC, goal to minimize impact due to lack of bandwidth/resource on both sides, but for R2 or beyond, long term approach is TBD, various options still under assessment - CDP-PAL, Cloudify, something else??Comment: If they move to a model approach, this is a much larger impact
- OOM
- Invited David (OOM PTL) to join us for next meeting (7/19)
- OOM still waiting on seed code, which applications may be impacted is still not clear.
- Question: Who is responsible for packaging app to work with OOM - does OOM take care of it or are instructions provided to each app to ensure proper packaging.
- HA/Resiliency
- Sharon has some suggestions for capabilities around resiliency that she would like to review with the team.
- We will plan to focus part of next meeting on this. Sharon will provide a presentation on resiliency/clustering
- Other topics
- Integration Testing with AAI & SDC - investigating to see what we can do locally
- Areas of interest from the team? No feedback received.
- Volunteer to start working on APPC-13 (replace openecomp with ONAP) - no volunteers yet
- Update M1 template (Randa to update)
- Update dependencies details
- Add CDP-PAL support if MultiVIM is to be part of R1
- Add risks
- Carbon coming end of July, If SDNC runs into issues, could be later; the ODL docker is a fundamental dependency for APPC.
- Update dependencies details
- SO & APPC interface
- Questions received on workflow dependencies between SO and APPC. Response provided: Follow-up discussions will be scheduled as needed.
From an APPC perspective, it manages Layer 4-7 configuration and life cycle management. APPC exposes a REST API that is accessible via DMaaP and would support the SO adapter calling APPC for any of its workflow engines. The way APPC is architected, it’s model driven, so how the invoking entity is architected is transparent to APPC. APPC strives to be completely agnostic of the network and make no assumptions. The APPC behavior is identified in the model/information sent to APPC. From an APPC perspective, it does not matter who is the calling entity, but the preferred approach is to call API via a message bus, not direct REST call. APPC provides a DMaaP message bus library which is used by callers in ONAP if they choose to use DMaaP. A similar library would be needed if a different message bus is used.
Paul Miller, one of our APPC architects gave a nice presentation on the model driven approach for APPC, which is recorded and may be of interest.
- Questions received on workflow dependencies between SO and APPC. Response provided: Follow-up discussions will be scheduled as needed.