Uploaded image for project: 'OpenNMS'
  1. OpenNMS
  2. NMS-8404

storeByForeignSource breaks node[N] style resource IDs



    • Bug
    • Status: Resolved (View Workflow)
    • Major
    • Resolution: Fixed
    • 17.1.1
    • Meridian-2016.1.0, 18.0.1
    • Architecture
    • Security Level: Default (Default Security Scheme)
    • Any system with {{storeByForeignSource=true}} set


      Steps to reproduce (note that this problem has additional repercussions outside the use case described below):

      1. Install and minimally configure an SNMP agent on the server
      2. Set storeByForeignSource=true and restart OpenNMS
      3. Add a node for the server via a requisition
        provision.pl node add TestOne 1234 hognose
        provision.pl interface add TestOne 1234
        provision.pl interface set TestOne 1234 snmp-primary P
        provision.pl interface set TestOne 1234 status 1
        provision.pl requisition import TestOne
      4. Get a coffee to give SNMP data collection a moment
      5. Request some data from the Measurements ReST API for the node, identified by its foreign-source name and foreign-ID:
        curl -u admin:admin ""
      6. Request the same data for the node identified by its database ID:
        curl -u admin:admin ""

      Expected result:
      Both styles of node identification result in retrieval of data

      Actual result:
      Only the nodeSource style works. When using node, we get back an error message:

      Resource or attribute not found for QueryRequest{Step=300000, Start=1462470034362, End=1462477234362, Max Rows=30, Interval=null, Heartbeat=null, Sources=[Source{Label=CpuRawUser, Resource ID=node[1].nodeSnmp[], Attribute=CpuRawUser, Datasource=CpuRawUser, Transient=false}], Expressions=[], Filters=[]}

      This situation results in API calls potentially breaking if the setting of storeByForeignSource changes to true. The choice of which style to use in a given situation should be a matter of convenience, not driven by the value of a configuration setting that a typical front-end developer cannot be expected to take into consideration.


        Issue Links



              j-white Jesse White
              jeffg Jeff Gehlbach
              0 Vote for this issue
              3 Start watching this issue