Guidance from Oskar:

"I would prefer to have correct separation of responsibilities between NCMP and DMI plugins from the beginning if possible. This would mean that even if inventory is ‘hard-coded’, NCMP would receive the inventory information from the DMI plugin via sync or event over the standard DMI interface (currently being specified). Also, I think not even the ONAP DMI application container should include such file avoiding that custom images needs to be built. The agreed option is:

• Implement (temporary?) REST endpoint in the ONAP DMI plugin that allows passing this data."
  xNF id as a url param - POST /dmi/api/v1/inventory/cmHandles/ { "xnf-ids" : [ "some-id" ,"", ""]]}
  in open API we will document it as "internal use only" in the description
  This is dependent on dmi registration CPS-405 - dylan will have additional params. as part of this endpoint it will be an empty map

required info to provide to be able to access to 

• xNfId (~cm-handleId), mount-point can be formed using this info
  • no additional information required
• Consider bulk, multiple xNfId's (cm-handles) in one request  (probably convenient for E2E Slicing use case)