Hi, We have a requirement in one of the use cases we are working on. I think that this scenario is generic and hence asking for community feedback.
Trying to understand whether this scenario can be realized with existing capabilities (such as CDS) or require some additional enhancements. Scenario: - An infrastructure network-service (Infra) consisting of various VNFs and workloads in those VNFs. - An app network-service (App) consisting of various VNFs and workloads in those VNFs. - App is dependent on functionality offered by infra. - Infra can be brought up in multiple cloud-regions. - When App is brought up on a selected cloud-region, it is expected to use that cloud-region's infra workload functions via its API. - For this discussion, let us assume infra and app network-services have only one VNF. Challenge: - When user is instantiating App network-service, he/she needs to ensure that App VNF workloads are configured with right infra workload API endpoints, credentials and the stuff required to talk to infra workload webservices. - Say that apps can be brought up on say any of 100 cloud-regions at later time, how does user know infra workload endpoint information for all these instances? One out-of-band solution : - User to maintain a document/spreadsheet with all endpoint information for various infra instances. - User to refer to this document, while bringing up the app. Problems with above approach: - Manual and buggy. - On technical front: In some cases, at the time of app instantiation, user may not know the cloud-region and hence infra VNF instance on which app would be brought up on. This case happens when dynamic cloud-region selection is taken care by OOF (using various constraints such as distance, cost, latency, HPA, affinity and other rules). One possible solution (require enhancements in ONAP) is to maintain database of run time information of services on per VNF basis and leverage this when new service/VNF (app) is being instantiated). Something like this: 1. User brings up infra-service. 2. Since user knows the parameters (e.g API endpoints) this service exposes, let the user create the DB document with key as service+VNF+instance and document as set of parameters and values (via some GUI/CLI). Instance can be represented as "Cloud-region-id or customer id or combination of both" 3. User bring up app-service 4. For each VNF, ONAP will figure out the dependent service+VNF parameters (based on cloud-region selected by OOF) and use them to override values of app-service VNF parameters. Even here, there are user actions that can lead to mistakes. Automation of DB document creation is needed. For that, ONAP system need to know the parameters to put in. It means that we need to have some definition of parameters that are useful for other services that run on top of it. Also, there should be some discipline on using consistent parameter names among VNFs of dependent services and let us assume that this discipline is assumed. Does CDS help? Or is this scenario be realized only after implementing nested services? Thoughts and suggestions? Thanks Srini -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14799): https://lists.onap.org/g/onap-discuss/message/14799 Mute This Topic: https://lists.onap.org/mt/28953160/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
