On this:” After a successful instantiation, every network service is inventoried in AAI along with associated cloud region information. The requested functionality could easily be achieved by querying AAI over right params”
I understand that A&AI has information about the cloud-region for each VNF instance. I am not sure whether A&AI is currently used to put any VNF-service information such as reachability information and any other information. Can you point out the schema/API that can be used by one service/VNF to expose its parameter values? If this facility is available, then at least it will solve one problem where user does not need to maintain some external document themselves. Thanks Srini From: Kumar Skand Priya, Viswanath V [mailto:[email protected]] Sent: Sunday, January 6, 2019 10:22 AM To: Addepalli, Srinivasa R <[email protected]> Cc: [email protected]; [email protected]; de Talhouet, Alexis <[email protected]>; MALAKOV, YURIY <[email protected]>; Ranganathan, Dileep <[email protected]>; Raj, Rajamohan <[email protected]>; Chivukula, Srivahni <[email protected]> Subject: Re: [E] [Onap-arc] Orchestration scenario : Inter-service parameters - Simplification question & seeking suggestions Hi Srini, My 2 cents: IMHO, ONAP shouldn't have to discriminate between infrastructure network services vs application network services. I always see ONAP as a manager over Cloud regions of different assets and it does exists to perform automation of orchestration function. After a successful instantiation, every network service is inventoried in AAI along with associated cloud region information. The requested functionality could easily be achieved by querying AAI over right params. This doesn't have to be part of ONAP service or component. Any external system could still poke into AAI and read relevant data. So in your specific usecase, the App provider could write another app to do this sophistication, instead of burdening ONAP. BR, Viswa On Sun, Jan 6, 2019 at 9:38 PM Srini <[email protected]<mailto:[email protected]>> wrote: 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 (#14802): https://lists.onap.org/g/onap-discuss/message/14802 Mute This Topic: https://lists.onap.org/mt/28954824/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
