Bug 979051 - getAttributes doesn't search as it is expected
getAttributes doesn't search as it is expected
Status: CLOSED WONTFIX
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: condor-aviary (Show other bugs)
Development
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: grid-maint-list
MRG Quality Engineering
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-27 09:41 EDT by Martin Kudlej
Modified: 2016-05-26 15:33 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-26 15:33:34 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Martin Kudlej 2013-06-27 09:41:21 EDT
Description of problem:
I've tried function getAttributes and it doesn't as it is expected:

1)
I've tried to get attributes for all collectors(or any other resource):
[{'id': (ResourceID){
   resource = "COLLECTOR"
   pool = None
   name = None
   address = None
   sub_type = None
   birthdate = None
 }}]
and it fails:
[(AttributeResponse){
   id =
      (ResourceID){
         resource = "COLLECTOR"
         name = None
         address = None
      }  
   status =
      (Status){
         code = "NO_MATCH"
         text = "no such resource"
      }  
 }]

collector is there:
$ condor_status -collector

Name                 Machine               Running  IdleJobs  HostsTotal

Wallaby Configured P __hostname__        0        0         5

Results for other resources are wrong too.

2) I've tried to add pool as pool name. My pool name is:
$ condor_status -colle -l | grep -i pool
Name = "Wallaby Configured Pool@__hostname__"

So I've set it.
[{'id': (ResourceID){
   resource = "COLLECTOR"
   pool = "Wallaby Configured Pool@__hostname__"
   name = None
   address = None
   sub_type = None
   birthdate = None
 }}] 

[(AttributeResponse){
   id =
      (ResourceID){
         resource = "COLLECTOR"
         pool = "Wallaby Configured Pool@__hostname__"
         name = None
         address = None
      }  
   status =
      (Status){
         code = "NO_MATCH"
         text = "no such resource"
      }  
 }]   
Wrong response again. For all other resources is respond same.

What if pool means something else than pool name.

[{'id': (ResourceID){
   resource = "COLLECTOR"
   pool = "__hostname__"
   name = None
   address = None
   sub_type = None
   birthdate = None
 }}] 

[(AttributeResponse){
   id =
      (ResourceID){
         resource = "COLLECTOR"
         pool = "__hostname__"
         name = None
         address = None
      }  
   status =
      (Status){
         code = "NO_MATCH"
         text = "no such resource"
      }  
 }]   
Wrong again.

3) Search according "name":
[{'id': (ResourceID){
   resource = "COLLECTOR"
   pool = None
   name = "Wallaby Configured Pool@__hostname__"
   address = None
   sub_type = None
   birthdate = None
 }}] 
[(AttributeResponse){
   id =
      (ResourceID){
         resource = "COLLECTOR"
         name = "Wallaby Configured Pool@__hostname__"
         address = None
      }  
   status =
      (Status){
         code = "NO_MATCH"
         text = "no such resource"
      }  
 }]  

As it is written above collector in this pool has the same name as parameter name in call.

If I try hostname(classad Machine for collector) it works, but I think it is a bug:
[{'id': (ResourceID){
   resource = "COLLECTOR"
   pool = None
   name = "__hostname__"
   address = None
   sub_type = None
   birthdate = None
 }}]

In case of Master, Negotiator it works because they have classad Name equal to hostname.
In case of Any it finds nothing(not even Master or Negotiator).
Scheduler has also classad Name same as hostname and it doesn't find it.
I've tried another values of classad Name(condor_status -l -any | grep -i ^name) 

Name = "bz544371@__hostname__"
Name = "collector#__hostname__"
Name = "job#__hostname__"
Name = "query#__hostname__"
Name = "slot1@__hostname__"
Name = "slot2@__hostname__"
Name = "slot3@__hostname__"
Name = "slot4@__hostname__"
Name = "slot5@__hostname__"

and nothing has worked.

3) I've tried another attribute "pool" and it doesn't work with hostname value:
For example:
[{'id': (ResourceID){
   resource = "SLOT"
   pool = "__hostname__"
   name = None
   address = None
   sub_type = None
   birthdate = None
 }}]
Also I've tried pool name "Wallaby Configured Pool@__hostname__".

4) I've tried set "pool" and "name" and some(collector, master, negotiator) queries start to work.

5) I've tried set address with these values: "__ip__", "__ip__:9618", "<__ip__:9618>" and it didn't found anything for any resource type.

I've tried other combinations from address, pool, name with variable values and sometimes it produce result for some resources and sometime not.

6) I've tried to search according "resource" and "sub_type" and set values from classads "MyType" and "MinorType".

Could you please write here functional specification?
what to put to pool, name, address, sub_type, birthdate and their mapping to classads in HTCondor for every resource type.


Version-Release number of selected component (if applicable):
condor-7.8.8-0.11.el6.x86_64
condor-aviary-7.8.8-0.11.el6.x86_64
condor-aviary-common-7.8.8-0.11.el6.x86_64
condor-wallaby-base-db-1.25-1.el6_3.noarch
condor-wallaby-client-5.0.5-2.el6.noarch
condor-wallaby-tools-5.0.5-2.el6.noarch
python-condorutils-1.5-6.el6.noarch
python-qpid-0.18-4.el6.noarch
python-qpid-qmf-0.18-15.el6.x86_64
python-wallabyclient-5.0.5-2.el6.noarch
qpid-cpp-client-0.18-14.el6.x86_64
qpid-cpp-client-devel-0.18-14.el6.x86_64
qpid-cpp-client-devel-docs-0.18-14.el6.noarch
qpid-cpp-client-ssl-0.18-14.el6.x86_64
qpid-cpp-server-0.18-14.el6.x86_64
qpid-cpp-server-cluster-0.18-14.el6.x86_64
qpid-cpp-server-devel-0.18-14.el6.x86_64
qpid-cpp-server-ssl-0.18-14.el6.x86_64
qpid-cpp-server-store-0.18-14.el6.x86_64
qpid-cpp-server-xml-0.18-14.el6.x86_64
qpid-java-client-0.18-7.el6.noarch
qpid-java-common-0.18-7.el6.noarch
qpid-java-example-0.18-7.el6.noarch
qpid-jca-0.18-8.el6.noarch
qpid-jca-xarecovery-0.18-8.el6.noarch
qpid-qmf-0.18-15.el6.x86_64
qpid-tools-0.18-8.el6.noarch
ruby-condor-wallaby-5.0.5-2.el6.noarch
ruby-qpid-qmf-0.18-15.el6.x86_64
ruby-wallaby-0.16.3-1.el6.noarch
wallaby-0.16.3-1.el6.noarch
wallaby-utils-0.16.3-1.el6.noarch


How reproducible:
100%
Comment 1 Anne-Louise Tangring 2016-05-26 15:33:34 EDT
MRG-Grid is in maintenance and only customer escalations will be considered. This issue can be reopened if a customer escalation associated with it occurs.

Note You need to log in before you can comment on or make changes to this bug.