[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HTCondor-users] remote Schedd using the python bindings, w/o passing thru the Collector

On 10/17/2018 10:55 AM, Jose Caballero wrote:
> Hi,
> using versions either 8.6 or 8.7
> According to the documentation, if I understand it correctly, to get a
> remote Schedd object, one can go thru the Collector
>      scheddAd = htcondor.Collector().locate(htcondor.DaemonTypes.Schedd, address)
>      schedd = htcondor.Schedd(scheddAd)
> If the Collector is also remote, then one has to do first something like this:
>      collector = htcondor.Collector(address)
> and then you can query that collector object.
> That works.

Glad to hear it! :)

> Now, I would like to be able to create the Schedd object when I don't
> know the address of the Collector.
> I am trying to build by hand the scheddAd for that purpose.

Maybe this can help.... be aware upon startup the schedd writes out the 
classad you need into a file specified by config knob 
/var/lib/condor/execute/spool/.schedd_address on Centos RPM).

> The bare minimum seems to be just one classad:
>        scheddAd = classad.ClassAd()
>        scheddAd['MyAddress'] =
> '<555.555.555.555:9618?addrs=555.555.555.555-9618&noUDP&sock=1786027_8b8d_4>'
> but for that to work, apparently, all fields in that string are
> needed, not just IP and port.
> I was wondering if someone has a clue about the part "
> &noUDP&sock=1786027_8b8d_4 "

As you discovered, you need more than just the IP address and the Port 
if you are using the condor_shared_port service (which is on by default) 
which allows multiple daemons to share the same listen port.  When your 
client contacts port 9618, that "sock=xxx_xxx_xxx" stuff in the 
MyAddress attribute tells the condor_shared_port if the client wants to 
be connected to the condor_master, or the condor_schedd, or a 
condor_shadow, etc.

If you want to contact a schedd from a client that cannot get the 
complete MyAddress attribute either from the Collector or from the 
SCHEDD_ADDRESS_FILE, the only option I can think of is to pick a 
well-known port (other than 9618) and tell your schedd to bind to that 
port in addition to responding to clients using the well known port 9618 
that is managed by the shared_port daemon.

For instance, lets say you wanted to have the schedd also listen to port 
9619.  To do this, append the following to your config file:

     SCHEDD_ARGS = -p 9619

Then I think your client could just use
    MyAddress = <xxx.xxx.xxx.xxx:9619>

You will want to make sure your firewall allows connections to port 9619 
in addition to 9618...

Hope the above helps,