All, Srini identified that VNFs might require a Real-time Service Registration for VNFs.
I wanted to let you know that AAF already has a real time Service Locator, that includes the following information: Name: Hierarchical name of service – (i.e. org.onap.aai) hostname: FQDN port: (obvious) latitude: When more than one instance exists, use with longitude to determine closest service via Great Circle longitude: When more than one instance exists, use with latitude to determine closest service via Great Circle version: (major, minor patch, pkg) to support increasing Versions realtime and pick best version of Service (i.e. A client that only knows about version 1.0, will get a service with supports that Interface Version) protocol: ex: https subprotocol: extra info, example: “'TLSv1.1', 'TLSv1.2'”, indicating that client needs at least TLS 1.1 to talk to this service. How it might help you: 1. Current AAF version relies on Public FQDN, which, given K8s, would correlate to multiple K8s Service Implementations 2. Resilient and Global in scope (Lat/Long allows talking to remote service that is closest, when possible, but also allows contacting any service, if closer ones are not available) What is already happening in Dublin: 1. I am already designing/half implemented how to handle “K8S Internal names” (i.e. K8s <ns>.<service> i.e. onap.aaf_service) versus standard Public Names (FQNS known by DNS) Please let me know if you interested in hearing about this existing element, what may work for you today, etc. -- Jonathan Gathman Principled-System Architect ATO Tech Dev/SEAT/Platform Architecture and Technology Management AT&T Services, Inc. 2349 Oaker, Arnold, MO 63010 m 314-550-3312 | [email protected]<mailto:[email protected]> From: <[email protected]> on behalf of Srini <[email protected]> Date: Sunday, January 6, 2019 at 10:08 AM To: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Cc: "'de Talhouet, Alexis'" <[email protected]>, "MALAKOV, YURIY" <[email protected]>, "Ranganathan, Dileep" <[email protected]>, "Raj, Rajamohan" <[email protected]>, "Chivukula, Srivahni" <[email protected]> Subject: [Onap-arc] Orchestration scenario : Inter-service parameters - Simplification question & seeking suggestions 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 (#14814): https://lists.onap.org/g/onap-discuss/message/14814 Mute This Topic: https://lists.onap.org/mt/28962690/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
