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]> 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 (#14801): https://lists.onap.org/g/onap-discuss/message/14801 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]] -=-=-=-=-=-=-=-=-=-=-=-
