Uploaded image for project: 'Configuration Persistence Service'
  1. Configuration Persistence Service
  2. CPS-1268

Spike: Alternate solution (interface) for module-sync use-case

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Duplicate
    • Icon: Medium Medium
    • None
    • None
    • DMI, NCMP
    • None

      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

      1. Design Spec in ONAP Wiki
        1. Interface impacts
        2. impact on current NCMP solution
        3. impacts on Model Adapter Impl
        4. Expected improvements (depend on profiling)
      2. Reviewed and agreed by Team and Stakeholder

       

      Spike Analysis : 

      -------------------

      1. Modify regsiterCmHandle to include a cmHandleModelId identifier to uniquely represent/identify the module set associated with a cmhandle.
      2. 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.
      3. 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% 
      4. 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.
      5. 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" : 

      {             ......         }

          }]

      }

            kieranmccarthy kieranmccarthy
            ToineSiebelink Toine Siebelink
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: