Date
16:00 UTC / noon EDT / 18:00 CEST
Zoom: https://zoom.us/j/619914482
Discussion items
Time | Item | Who | Notes |
---|---|---|---|
00:00 | Admin | Next meeting: 2020-07-15 | |
O-RAN-SC | New Use case: App Life Cycle Management (LCM) Questions
| ||
PoC | Tracy Van Brakle | PoC end of Sep - more enhanced first week of Dec
| |
NETCONF-638 | Jeff Hartley | -- quick follow up Info:
Self Termination of NetConf SessionsSource: O-RAN Specification - O-RAN.WG1.O1-Interface.0-v03.00 O-RAN-SC wiki: https://wiki.o-ran-sc.org/display/OAM/Termination+of+NetConf+Sessions O-RAN-SC wiki: https://wiki.o-ran-sc.org/display/OAM/Architecture+discussion+for+Non-Permanent+NetConf+Sessions O-RAN-SC Jira: https://jira.o-ran-sc.org/browse/OAM-1 OpenDaylight Jira: https://jira.opendaylight.org/browse/NETCONF-638 | |
NetConf Session | Thanks Jeff | Process to establish a NetConf session |
1 Comment
Pawel Slowikowski
As I mentioned during the meeting, I would like to understand the rationale behind LCM for R-APPs. There are many possibilities where R-APPs will be installed in real environments: ONAP kubernetes, external kubernetes, public/private clouds (e.g. Azure ML), OpenStack and so on.
Looking at some design documents:
an R-APP could be anything: a ML model, service with some logic, UI, database etc.
Different platforms have their own LCM mechanisms and building another carrier-grade cloud system for R-APPs to wrap up pacakging and deployment seems to take extremely long time with high risk.
Our proposal is to build reference R-APPs in ONAP based on DCAE apps/cloudify. This mechanism has been already in place and fits quite good in the idea of R-APPs.
Maybe it would be good to start with non-RT RIC and specification of R1 interface, and then based on experience with different R-APPs decide whether strict or standardized LCM for R-APPs is needed or not.
* LCM for X-APPs is something completely different and I am not referring to it.