Test Environment:
OS: CentoOS 7.6
Python : 2.7 and 3.4
xdinfo: 1.4.1
Test case four specifies testing xifno information types that can take a match string option using a SiteID and a ResourceID as the match string. With both python2.7 and Python 3 information types resources, software and outages produce not output with these match strings without using the modifier "on". The services information type does produce output.
Examples: $
$xdinfo res comet.sdsc.xsede.org
$ xdinfo res stampede2.tacc.xsede.org
$ xdinfo resources tacc.xsede.org
$ xdinfo software sdsc.xsede.org
$ xdinfo outages stampede2.tacc.xsede.org past
$ xdinfo outages comet.sdsc.xsede.org past
$ xdinfo outages sdsc.xsede.org past
The services information type produced output using the same input.
$ xdinfo services stampede2.tacc.xsede.org
Type Name ResourceID URL
openssh org.globus.openssh stampede2.tacc.xsede.org stampede2.tacc.xsede.org:2222
gridftp org.globus.gridftp stampede2.tacc.xsede.org gsiftp://gridftp.stampede2.tacc.xsede.org:2811/
$ xdinfo services tacc.xsede.org
Type Name ResourceID URL
openssh org.globus.openssh wrangler.tacc.xsede.org wrangler.tacc.xsede.org:2222
openssh org.globus.openssh stampede2.tacc.xsede.org stampede2.tacc.xsede.org:2222
gridftp org.globus.gridftp stampede2.tacc.xsede.org gsiftp://gridftp.stampede2.tacc.xsede.org:2811/
gridftp org.globus.gridftp wrangler.tacc.xsede.org gsiftp://gridftp.wrangler.tacc.xsede.org:2811/
As did using the "on" or "at" modifier.
$ xdinfo res on comet.sdsc.xsede.org
info_resourceid resource_descriptive_name rdr_type
comet.sdsc.xsede.org SDSC Dell Cluster with Intel Haswell Processors (Comet) resource
comet.sdsc.xsede.org SDSC Dell Cluster with Intel Haswell Processors (Comet) compute
$ xdinfo res on sdsc.xsede.org
info_resourceid resource_descriptive_name rdr_type
oasis-dm.sdsc.xsede.org SDSC Medium-term disk storage (Data Oasis) storage
oasis-dm.sdsc.xsede.org SDSC Medium-term disk storage (Data Oasis) resource
comet.sdsc.xsede.org SDSC Dell Cluster with Intel Haswell Processors (Comet) resource
comet.sdsc.xsede.org SDSC Dell Cluster with Intel Haswell Processors (Comet) compute
comet-gpu.sdsc.xsede.org SDSC Comet GPU Nodes (Comet GPU) resource
comet-gpu.sdsc.xsede.org SDSC Comet GPU Nodes (Comet GPU) compute
]$ xdinfo res at sdsc.xsede.org
info_resourceid resource_descriptive_name rdr_type
oasis-dm.sdsc.xsede.org SDSC Medium-term disk storage (Data Oasis) storage
oasis-dm.sdsc.xsede.org SDSC Medium-term disk storage (Data Oasis) resource
comet.sdsc.xsede.org SDSC Dell Cluster with Intel Haswell Processors (Comet) resource
comet.sdsc.xsede.org SDSC Dell Cluster with Intel Haswell Processors (Comet) compute
comet-gpu.sdsc.xsede.org SDSC Comet GPU Nodes (Comet GPU) resource
comet-gpu.sdsc.xsede.org SDSC Comet GPU Nodes (Comet GPU) compute
Hey Chris,
This is working as designed, but arguably not well designed.
For resource, software, and outages the search strings are compared to descriptions. For services the search strings are compared to the service endpoint, which in this case happens to have the resource's id and site embedded (comet.sdsc.xsede.org, tacc.xsede.org, etc.)
Since out Site IDs and Resource IDs are meant for human consumption, it does make sense that a search string should be compared to those two fields as well as descriptions.
I'm recording your input as an enhancement request since the current behavior isn't intuitive. I think a better design is that the "on <whatever>" or "at <whatever>" narrowly look for information about a specific resource or at a site. However, if a search string is specified without "on" or "at" then that string should be search for in all available fields.
Does that design make sense to you?
Thanks for running the tests and reporting these helpful results.
JP