perfSONAR User Q&A and Other Discussion

["Andrew Lake" <>]

Hi,

It’s perfectly valid to use no_agent in disjoint. Looks like a copy/paste error on that page. Also, you should see http://docs.perfsonar.net/3.5rc2/config_mesh.html?highlight=disjoint#no-agent-directive. The section of the documentation to which you are pointing is referring to a different form of no_agent that can be defined in a <group> element, not the form you are using which is defined in the <host> element. 

Could you share you full mesh .conf file or a link to your JSON file? I wouldn’t mind trying to run it against the 3.5 code that will be out in a couple days to see if the same behavior is observed.

Thanks,

Andy

On Thu, Sep 24, 2015 at 3:37 PM, Hyojoon Kim <> wrote:

Hi, 

We use a central mesh configuration, and one of the groups is a “disjoint” type. It seems an owamp test using this group runs into a problem. More exactly, the measurement nodes that pull the central mesh configuration create an incomplete test instance in their “regular_testing.conf” files. 

To be more precise, in the below example, host “1.1.1.1” and “1.1.1.2” each generates a test towards “2.2.2.3", but not to 2.2.2.1” nor towards “2.2.2.2"

<group cdn_latency>

  type              disjoint

  a_member          1.1.1.1

  a_member          1.1.1.2

  # This should list all BDF sensor nodes.

  b_member          2.2.2.1

  b_member          2.2.2.2

  b_member          2.2.2.3  # host with no_agent=1 in its host directive.

</group>

   <host>

      description   2.2.2.3

      address       2.2.2.3

      no_agent      1

...

We think this is because we have a host in the “b_member” that has “no_agent 1” defined in its host directive (host “2.2.2.3”). The documentation seems to suggest that the "no_agent” option should not be used in the the disjoint group type.  (http://docs.perfsonar.net/3.5rc2/config_mesh.html?highlight=disjoint#config-mesh-group-no-agent). 

Is this really the case? FYI, the JSON generation script (/opt/perfsonar_ps/mesh_config/bin/build_json) did not spit out an error message when a host that has “no_agent   1” defined in its host directive is used in either a_member or b_member in a disjoint group type. We think the “no agent” option is the cause because removing “b_member  2.2.2.3” from the above group solves the problem: Host “1.1.1.1” and host “1.1.1.2” each generates test towards “2.2.2.1” and “2.2.2.2” after the removal.

Can someone comment on this situation? We are still on version 3.4.2. 

Thanks,

Joon