Service Instance thoughts

At the Montreal joint architecture/modeling meeting, there was discussion on network service vs. service. Data was presented regarding the fields needed in the instance data model by AAI and VFC. I attempted to capture an initial proposal for comment.

There are a number of items that I need more understanding about:

what are nsdmodel, scaleparameters, and inputparameters?
flavourid and nslevel seem like they should be relationship to other entities instead of "foreign keys", is that true?

In addition, we need a discussion on some items:

AT&T has used a type/role/function classification function to provide a standard way to encode some data for filtering that is used in place of descriptions. I'd like to propose that for consideration instead of a free form description field (or a field that takes different ungoverned values based on the flow being written). Establishing data governance around these values can be instrumental for your operations teams and your automation.
It's like to propose a datatype for "ProviderDetails" which captures fields like the descriptorId, descriptorVersion, productName, packageId, etc. A property of type ProviderDetails would be added to the internal design time model for Service and NetworkFunction.

Let's use three terms:

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)
PlatformServiceModel (which is what SDC produces as the service model that the components use)
ServiceInstance (the results of an instantiation from the PlatformServiceModel)

@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:

@Fernando Oliveira

@Yan Yang

@LIN MENG

But all are welcome.

AAI	VFC	What is it	Belongs in	Action
service-instance-id	id	unique id of the instance	ServiceInstance	keep service-instance-id as the key to the AAI service instance and adapt id to populate it.
	nspackageid	unique id of the package	PlatformServiceModel	Add providerDetails data type of which this would be a property, add a property of type providerDetails to PlatformServiceModel
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 PlatformServiceModel model	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 PlatformServiceModel model	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	PlatformServiceModel, 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	PlatformServiceModel, 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	PlatformServiceModel, could be copied to ServiceInstance	Add providerDetails data type of which this would be a property, add a property of type providerDetails to PlatformServiceModel model
	sdncontrollerid		ServiceInstance	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.