...
- OnboardingServicePackage contains the OnboardingServiceDescriptor among other things
- OnboardingServiceDescriptor (of which one format is the SOL 001 NSD - a point of contention here as to whether this is any different than creating an ONAP service in the designer)
- InternalServiceModel PlatformServiceModel (which is what SDC produces as the service model that the components use)
- ServiceInstance (the results of an instantiation from the InternalServiceModelPlatformServiceModel)
Chesla Wechsler to take action item to write up schemaless behavior need which would accommodate service-level properties which are not global (i.e., do not belong in the STANDARD COMMON definition of service-instance) but which still need to be stored on certain service-instance to which they apply. Chesla will talk to AAI PTL about this, as this is a feature that would be needed on AAI.
Schemaless behavior (note, I haven't spoken to the AAI PTL yet):
The internal service model global type has properties and attributes which are common to all service-instances. This is likely a very small set. When a node type extends the service global type, it adds properties and attributes specific to that particular service model (like your portal url, slice characteristcs, etc.).
Today, AAI expects the fields in its payloads to be defined by an OXM file, and the relationships between vertexed defined in an edge rules file. It uses a "superset of all possibilities" approach which I think should evolve to an InternalXModel approach where the specific InternalModel, which has properties and attributes, defines the fields of the instance. Alternatively, there would need to be instances modeled at the same time as the design time objects and mapping ensues.
AAI would need an interface that permits payloads that have the specific properties and not just the common/global ones in the base object.
AAI stores all the data in the payload and returns it when queried, which includes things like portal url, etc.
The common/global fields can be indexed. Model specific ones would not have an index at first unless they is also an AAI feature to ask for an index on it or there is a way to specify it in the model.
People I'm expecting to participate in this conversation are as follows:
Former user (Deleted)Fernando Oliveira
But all are welcome.
...
| AAI | VFC | What is it | Belongs in | Action | |
| service-instance-id | id | unique id of the instance | ServiceInstance | keep in service-instance-id as the key to the AAI service - instance and adapt id to populate it. | |
| nspackageid | unique id of the package | InternalServiceModelPlatformServiceModel | Add providerDetails data type of which this would be a property, add a property of type providerDetails to InternalServiceModelPlatformServiceModel | ||
| service-instance-name | name | name of the instance | ServiceInstance | keep in AAI service-instance | |
| description | description of the instance | ServiceInstance | Free form human readable string which no software should interpret or do logic on. Purely to display to a human. | ||
| model-invariant-id | invariant id across all versions of the same InternalServiceModel PlatformServiceModel modelInternalServiceModel | PlatformServiceModel | keep in AAI service-instance API (I think it's really a relationship internally) | ||
| model-version-id | unique id of a version of a model in the InternalServiceModel PlatformServiceModel modelInternalServiceModel | PlatformServiceModel | keep in AAI service-instance API (I think it's really a relationship internally) | ||
| service-type | should be discussed, should just be denormalized filtering data that has a data steward | InternalServiceModelPlatformServiceModel, could be copied to ServiceInstance | Data Governed field which is used in filtering | ||
| service-role | should be discussed, should just be denormalized filtering data that has a data steward | InternalServiceModelPlatformServiceModel, could be copied to ServiceInstance | Data Governed field which is used in filtering | ||
| service-instance-location-id | retire | retire | Discuss merits of having a customer-premise "table" and establish relationship | ||
| bandwidth-total | retire | retire | retire | ||
| property-value | We think this is an error | retire | remove | ||
| environment-context | extension, not required | ServiceInstance | ignore for now, may be renamed | defines the use and criticality of a virtual function which is used to ensure hypervisor separation (non-shared hosts) between vf functions of different use or criticality (e.g. Critical_Revenue-Bearing, Useful_Non-Revenue) | |
| workload-context | extension, not required | ServiceInstance | ignore for now, may be renamed | describes the purpose. VNF End-to-End testing for the Casablanca release would be VNF-E2E-Casablanca as an example | |
| vnf-type | was this a typo on the slide? This is not in AAI in ONAP. | I think this is a mistake | |||
| created-at | createtime | refactor, just expose AAI data but as system set, read only | ServiceInstance | expose, needs to be read only | Check with AAI PTL on these fields |
| updated-at | lastuptime | refactor, just expose AAI data but as system set, read only | ServiceInstance | expose, needs to be read only | Check with AAI PTL on these fields |
| persona-model-id | retire | remove | |||
| widget-model-id | retire | remove | |||
| widget-model-version | retire | remove | |||
| vhn-portal-url | This should not be on the global type but the derived type would have it and it could be stored as a schemaless field on the service-instance vertex | refactor | |||
| orchestration-status | status | SO has an enumeration of values. VFC probably does too and odds are they aren't the same. VFC: empty, instantiating, terminating,active, failed, inactive, updating, scaling, healing SO: Inventoried, Assigned, Active | Propose adding a vfc-status field to AAI to capture VFC's status, and revisit this as a community to see if there can be convergence on a state transition for services. SO uses terminal states and VFC seems to use transitional and terminal states. | LIN MENG will get enumerated values from VFC PTL to see whether they can be mapped into the enumerated values used by SO so that there is one set of enumerated values. Chesla Wechsler to propose to the architecture subcommittee that we need an orchestration "meeting of the minds" on state transitions, terminal states and transition states and what gets written to AAI. Update: topic created | |
| nsdId | Unique ID of the network service descriptor | InternalServiceModelPlatformServiceModel, could be copied to ServiceInstance | Add providerDetails data type of which this would be a property, add a property of type providerDetails to InternalServiceModel PlatformServiceModel model | ||
| sdncontrollerid | ServiceInstanceDiscuss | Do Not Add to AAI | LIN MENG will check what this is with the PTL. | ||
| nslevel | propose calling it instantation-level (so much indirection in the ETSI NFV types….) | ServiceInstance | Discuss whether this is a relationship to another entity. Propose adding non-required instantiation-level field to AAI. Need ONAP to work on the solution for service scaling. What release should we propose service scaling be handled? | Need to discuss service level as a class and see how they fit into the overall ONAP architecture and possibly create a vertex type within AAI which would then have a relationship with the service-instance. This would be an edge, not a field in service-instance. LIN MENG - would you be willing to get the ETSI definition for the service level and flavor Perhaps get the table definitions? Really want ETSI definition too though. Chesla Wechsler to send email to Alla G regarding whether there will be any use cases which will need to leverage service deployment flavors and instantiation level At info model level, you can always add instantiation level and deployment flavor to the service instance as Future stereotype, and data modelers know that they don't need to be added. Update: Please see thread No need to worry about flavour_id or nslevel in Dublin per Use Case committee. | |
| flavourid | where is the data model definition of this? Can a flavour be a object with name/value pairs which is referred to by the service model and is common for all instances created from this service model? | ServiceInstance | Discuss whether this is a relationship to another entity If there is no support today or in Dublin for more than one flavor, propose deferring this to that time. Regarding instantiation level and flavor in general (scaling), let's learn from the network function first and then see if it can apply to the service. | See above for use case email. | |
| nsdmodel | JSON string | Do not add to AAI | LIN MENG will provide an example of an entire row of this table, with nsdmodel, scaleparameters, inputparameters populated. | ||
| scaleparams | What is this? Is this just an internal field of VF-C? I don't see it referenced in the etsi.nfv.nodes.NS | Do not add to AAI | |||
| resource-version | Used for concurrency enforcement with clients of AAI | ServiceInstance | keep | ||
| input-parameters | inputparameters | For SO to pass parameters for closed loop, does this have ONAP wide applicability for closed loop functions? | Do not add to AAI | ||
| selflink | The purpose of this field is to give a URL to the source of truth of the service-instance. | Chesla Wechsler to find out if this is used in the service-instance. Answer: yes It can be used to contain the URL to the service topology in SDN-C, for example. | |||
| global-customer-id | This is VF-C's denormalization of customer data into the service instance. AAI captures this in the customer vertex type. The customer has a relationship to a service subscription which has a relationship to the service-instance and therefore this data is avaialble but needs to be derived. | Use the customer.global-customer-id field. Do not put into service-instance. |