Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

#IssueNotes Decision
1Type of Interface REST or KafkaREST
  1. easier/cheaper
  2. possibly (complete) re-use of (inventory) existing interface
  3. well documented by OpenAPI
  4. support test stubs (contract testing)

Kafka

  1. more complicated/costly
  2. plethora of topics and messages, not well documented (no standard)
  3. More robust (request persisted until acknowledged)

meeting Agreed to use REST interface.  

2ModuleSetTag moduleSetTag based on Hash no (yet) implemented!

This study seems to assume the module set tag is already implemented but it isn't!


[kieran mccarthy]:  the request it to introduce the module set tag/identifier of some kind for this new upgrade usecase.  Not assuming it is there already.  Will be costlier but is important for performance to avoid pulling models if they are already known to NCMP.
3Expected Responses

when and what content?

  1. just acknowledge upon receipt
  2. response on completion

202 Accepted if there are no issues with the payload
     - request payload is well formed 
     - all cmhandles are valid

404 Not Found Reject the request if an unknown cmhandle is sent in

4Should CM-Handle state change (e.g. to 'locked')  'during' upgrade?Yes but is important to not be locked for long which makes it important to use the moduleSetTagShould be set to LOCKED until the new moduleSet is associated with the cmhandle.  I think there is a LOCKED_UPGRADING if I remember right.  Lock reason should state "upgrade initiated at time xxx for new moduleSetTag xyz".  When lock is being removed any lockReason message should be cleared. 
5ModuleSetTag moduleSetTag is Optional (owned and defined by DMI Plugin)Support for upgrade without continues using delete/add cm handle approach.
If the update includes an ModuleSetTag moduleSetTag it would be considered an upgrade

meeting Agreed to use REST interface with "upgradedCmHandles". 

6ModuleSetTag moduleSetTag should be able to be used during initial inventory too!Initial Inventory should be sped up too (capability requirements impacts ?!)
7Exact name ModuleSetTag moduleSetTag

meeting agreed on ModuleSetTag moduleSetTag

8How to store: hardcoded (postgress schema), inventory yang model or as additional property (private or public)? update Inventory Yang Model so it can be queried (without code changes!) like other aspect such as 'state'

meeting agreed to update Yang Model

Is it  ok for cmhandle to send out a cmhandle lcm update event for a change in this property to indicate to client applications that a new moduleSet is available?  

9additional operation for inventory Interface: 'upgradedCmHandles'
The interface currently supports
  1. createdCmHandles
  2. updatedCmHandles
  3. removedCmHandles

it possiblycould be done as part of 'updatedCmHandles' and look for /recognize the moduleSetTag update but this would be messy and confusing, also thentheoretically properties could be updated as the same time as the module set..

 Toine Siebelink , changed updatedCmHandles to removedCmHandles as per openAPI.

 

meeting agreed 


...

Making the module upgrade request either over REST or Kafka Event with a supplied 'ModuleSetTagmoduleSetTag' property will indicate to NCMP that a cmhandle has a new moduleSet (node has been upgraded).  The ModuleSetTag moduleSetTag is a unique identifier for the set of modules associated with a cmhandle. This event or rest request will trigger ncmp to either retrieve the new module set for this cmhandle from the dmi plugin or if NCMP is already aware of ModuleSetTag moduleSetTag as part of a previous retrieval for a set of modules for a cmhandle that supplied this ModuleSetTag moduleSetTag then it should not re-retrieve the modules from the dmi plugin as it already has them.  NCMP should use its stored ModuleSetTag moduleSetTag to get the set of modules.  It can then do a delta with the existing cmhandle moduleSet and update the moduleSet for the cmhandle.

The above proposal would require model updates to NCMP to store the association between a ModuleSetTag moduleSetTag supplied by a dmi-plugin (during and updateCmHandles request) and the modules.  Initially ModuleSetTag moduleSetTag is not known to NCMP.  However, after retrieval of the modules for the first time for the cmhandle, NCMP can store the association.  Any subsequent cmhandle that references the same ModuleSetTag moduleSetTag will not require NCMP to go back to the dmi plugin for the moduleSet.

...

Code Block
languagexml
titleURI: POST /v1/ch requestbody
collapsetrue
{
    upgradedCmHandles : [      
      {
         "cmhandle" : "<cmhandle-id-1>",
         "ModuleSetTagmoduleSetTag" : "ffsdfg55342"   #  new ModuleSetTagmoduleSetTag ffsdfg55342 for the cmhandle        },       
      {
         "cmhandle" : "<cmhandle-id-2>",
         "ModuleSetTagmoduleSetTag" : "ffsdfg55342"   #  new ModuleSetTagmoduleSetTag ffsdfg55342 for the cmhandle        },     
      { 
         "cmhandle" : "<cmhandle-id-3>",    
         "ModuleSetTagmoduleSetTag" : "ddger34324"    #  new ModuleSetTagmoduleSetTag ddger34324 for the cmhandle         }
  ]
}

Support for upgrade without (empty)

...

moduleSetTag

If the ModuleSetTag moduleSetTag json property is set to "" (empty string) or then it should also indicate that the moduleSet for a cmhandle has been updated but there is no associated ModuleSetTag moduleSetTag available for that cmhandle.  This approach will always result is a full request to the dmi plugin for the module set for the cmhandle.

...