Examine the idea of having an additional parameter on the interfaces involved on module sync that can help NCMP to determine if it needs to get module references or not.
ie. a hash on the sorted list module-references
the assumption is that many nodes share the same list of module(reference)s. If the DMI Plugin could provide NCMP with the information to determine this during the original registration phase it could prevent a lot of communication for many cm handles and significantly improve the performance of the 10k module-sync use case.
A/C
- Design Spec in ONAP Wiki
- Interface impacts
- impact on current NCMP solution
- impacts on Model Adapter Impl
- Expected improvements (depend on profiling)
- Reviewed and agreed by Team and Stakeholder
Spike Analysis :
-------------------
- Modify regsiterCmHandle to include a cmHandleModelId identifier to uniquely represent/identify the module set associated with a cmhandle.
- The cmHandleModelId shall be an optional parameter. If provided, NCMP may use it during the discovery procedure to know if a previously discovered cmhandle with the same cmHandleModelId/module set has already been discovered. NCMP will then know to associate the previously discovered module set with the new cmHandle.
- Assuming there are say 10k cmhandles created from say 10 module sets, it means NCMP would only need to make a maximum of 10 requests to the DMI Plugin for the associated modules for ALL 10K cmHandles. Today, NCMP has to go to DMI Plugin 10k times, once for each cmhandle thereby reducing the number of calls to DMI Plugin by > 99%
- NCMP-DMI documentation should make it very clear that it is recommended that DMI Plugins always provide a model identifier (may be a module-set hash or something else for example) if possible and the consequence of not providing one may degrade discovery performance significantly. Note, it is left as an optional parameter during registration as the cmHandleModelId may not be known during the initial cmhandle registration. It is also required to be optional for backward compatibility.
- The cm handle registration interface proposal is in bold red below :
{
"dmiDataPlugin": "http://eric-eo-enm-adapter:80",
"dmiModelPlugin": "http://eric-oss-enm-model-adapter:8080",
"createdCmHandles": [{
"cmHandle": "cmhandle_id",
"cmHandleModelId" : "4473hdfhsfserf343", # This is an OPTIONAL parameter.
# NCMP may use it internally to determine if they have the associated
# module set already from a previously discovered cmhandle module set.
"cmHandleProperties":
{ ..... },
"publicCmHandleProperties" :
{ ...... }}]
}
- is duplicated by
-
CPS-1733 Upgrade YANG schema-set for CM handle without removing and adding it
- In Progress