...
| draw.io Diagram | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
You could put the 'ManagementReference' as attribute(s) of the Resource, but I think it is (1) a type of resource in its own right and (2) potentially structured information required to interface with the actual manager instance.
Any 'Resource' may be managed for a variety of arbitrary purposes (extendable ENUM) by different Management resources.
The management software may refer to an internal (to the ONAP deployment) or external Resource.
The management reference role enables a userof the topology to inter work with management software that respects access control (for example TBAC). A ManagementReference must have at least one ManagementReferenceRole. The MnagementReferenceRole is unique within a ManagmentReference The need for this is valid and useful. The 'managedBy', relationship may be promoted to the Resource level – to be less proscriptive. Note also that there will be multiple ManagementReference from a single Resource, potentially one for each management domain (e.g. Fault, Configuration, Performance subscription, etc. This also looks like a update to the 'Resource' in the ONAP IM.
Intent and services
Services
...