I tested the behaviour on a recent foundation-2023 branch today. We have to handle two cases. First, node X is a new node and second, node X already exists and needs to be updated. Furthermore we have a policy which also adds a category to node X. This is important to understand the current behaviour in my opinion. Here my results...

• Node X is new:

  • Scan all nodes (rescanExisting=true):

    • categories of requisition added

    • categories of policies added

    • assets added

  • Scan added nodes only (rescanExisting=false):

    • categories of requisition added

    • categories of policies added

    • assets added

  • No scanning (dbOnly):

    • categories of requisition added

    • categories of policies added

    • assets added

• Node X already exists:

  • Scan all nodes (rescanExisting=true):

    • categories of requisition updated

    • categories of policies updated

    • assets updated

  • Scan added nodes only (rescanExisting=false):

    • categories of requisition not updated

    • categories of policies still exist

    • assets updated

  • No scanning (dbOnly):

    • categories of requisition not updated

    • categories of policies still exist

    • assets updated

I also looked through the code. A new node is even scanned if dbOnly is given. The only real interesting case for me is when dbOnly is given and an existing node should be updated. Unfortunately we cannot distiguish on a sync whether categories of an existing node were added by the requisition or by policies. So, we only have two options at this point:

• we leave all categories untouched, so categories added by policies by previous runs still exist (current behaviour)

• we update the categories of the node, but in this case the categories added by the policies of previous runs are lost because there is no scan phase

So, from my point of view the current behavior is ok and the best we can do at this point.

Tests run by the customer:

• ASSET DATA CHANGE IN THE NODE REQUISITION

  • if you modify the asset in requisition and synch with dbonly ("No scanning") then DB update works

  • if you modify the asset in requisition and synch with rescanexisting=false ("Scan added nodes only") then DB UPDATE
    DOESN'T WORK (I think regardless of the scan success )

  • if you modify the asset in requisition and synch with rescanexisting=true ("Scan all nodes") then DB update works

  • if launch rescan from GUI (node page) or issue uei.opennms.org/internal/capsd/forceRescan, DB update works

• CATEGORY CHANGE IN THE NODE REQUISTION

  • From customer on v29: In all above conditions, if you update a category in requisition group from GUI or from API (POST
    /requisitions/{name}/nodes/{foreignid}/categories) , then CATEGORY IS NEVER UPDATED IN THE DB, even after any synch
    request.

  • From me on v31: I found that only a full rescan updates the category in the database. Selecting “Added Nodes Only” or “No Scanning” doesn’t apply category changes to nodes.

Basing on our tests here is the update workflow we implemented (nodes are of course stored in our CMDB and we
implemented a provisioning tool):

• get the node from the requisition group using the ForeignID and check it's attributes , assets and categories

• if any differ, POST the same node with updated values ( + add the interfaces and metadata from the fetched node ) to
  the req. group

• search for NodeID using the foreign ID using /opennms/rest/nodes?foreignId={ForeignID}&limit=1

  • fetch the node /opennms/rest/nodes/{NodeID}

  • check the values and update the assets using PUT /opennms/rest/nodes/{NodeID} 

  • check the categories and if they change , remove and re-add new category (DELETE
    /opennms/rest/nodes/{NodeID}/categories/{Category} and POST /opennms/rest/nodes/{NodeID}/categories)

  • scan requisition with rescanExisting=dbonly (it wouldn't hurt at this point)