Re: [HTCondor-users] persistency of generic ClassAds

[Thomas Hartmann <thomas.hartmann@xxxxxxx>]

Hi Brian,

yes, I am currently trying to dive into how to utilize best Condor's
ClassAds for some own configs/parameters/values ;)
(instead of setting up some dedicated key:value store (Zookeeper?) when
Condor probably offers all the necessary tools already)

Thanks for the links. As for own ads, I can confirm, that juggling with
them is somewhat cumbersome - I will see to stick to the common daemons'
ads instead.

Cheers and thanks,
  Thomas

On 2016-07-27 20:46, Brian Bockelman wrote:
> Hi Thomas,
> 
> Is this related to your previous question?  In that case, I might have sent you a bit in the wrong direction.
> 
> The easiest way to incorporate this sort of information is to get it the collector via *startd ad* or *master ad* (as you explore below, itâs kind of a pain to put it into a completely separate ad).
> 
> Putting extra information into an existing ad is far easier and (fairly) well documented:
> 
> http://research.cs.wisc.edu/htcondor/manual/v8.5/3_3Configuration.html#param:SubsysExprs
> 
> The STARTD_EXPRS or MASTER_EXPRS mechanism is going to be good for fairly static information (think: kernel version).
> 
> For more dynamic information, youâll want to use the STARTD_CRON, as documented here:
> 
> http://research.cs.wisc.edu/htcondor/manual/v8.5/4_4Hooks.html#SECTION00543000000000000000
> 
> At our site, we use this to report the health of CVMFS into the startd classad.  That allows us to have the START expression turn to UNDEFINED if CVMFS breaks.
> 
> Brian
> 
>> On Jul 27, 2016, at 5:32 AM, Thomas Hartmann <thomas.hartmann@xxxxxxx> wrote:
>>
>> Hi all,
>>
>> I some questions about their persistency
>>
>> - afais ClassAd key:value pairs cannot be updated individually but the
>> whole set has to be rewritten, or?
>>   I.e., after I set some generic ClassAds [1,2], I updated(?) the
>> generic set setting only one key-value-pair and followingly all
>> previously set but not mentioned again ClassAds became undefined [3,4]
>>
>> - how persistent are generic ClassAds? Will they survive a reboot of
>> the Collector, i.e., are they written to disk somewhere?
>>
>> - can I start with default values set by a node?
>>   I.e., Since I found no matching hits in a quick google search, I
>> already tried (without success), if one can set ClassAds similar to
>> adding daemon attributes [5]?
>>   - would that make actually sense? Or would any manually set ClassAd
>> be overwritten again the next time a node's master speaks with the
>> collector?
>>
>> Cheers and thanks,
>>  Thomas
>>
>> [1]
>>> test_batch0930.ad
>> MyType = "Generic"
>> TestKernel = "2.3.5"
>> TestDoStuff = True
>> TestStatusThing = "bar"
>> Name = "batch0930.desy.de"
>> Machine = "batch0930.desy.de"
>>
>> [2]
>>> condor_status -generic -constraint 'regexp(".*batch0930.*", Name)' -long
>> LastHeardFrom = 1469614306
>> AuthenticatedIdentity = "unauthenticated@unmapped"
>> MyAddress = "<131.169.56.33:0>"
>> UpdatesHistory = "00000000000000000000000000000000"
>> UpdatesLost = 0
>> UpdatesSequenced = 0
>> TestStatusThing = "bar"
>> Machine = "batch0930.desy.de"
>> TestDoStuff = true
>> TestKernel = "2.3.5"
>> UpdatesTotal = 6
>> Name = "batch0930.desy.de"
>> MyType = "Generic"
>>
>> [3]
>>> test_batch0930_2.ad
>> MyType = "Generic"
>> TestStatusThing = "ALERT"
>> Name = "batch0930.desy.de"
>> Machine = "batch0930.desy.de"
>>
>>
>> [4]
>>> condor_status -generic -constraint 'regexp(".*batch0930.*\.desy\.de",
>> Name)' -af name TestStatusThing TestDoStuff TestKernel
>> batch0930.desy.de ALERT undefined undefined
>>
>>
>> [5] # (GENERIC_ATTRS certainly wrong...)
>>> /etc/condor/config.d/99test.conf
>> GENERIC_TestKernel = False
>> GENERIC_TestDoStuff = False
>> GENERIC_TestStatusThing = False
>> TestKernel = False
>> TestDoStuff = False
>> TestStatusThing = False
>> GENERIC_ATTRS = TestKernel, TestDoStuff, TestStatusThing, $(GENERIC_ATTRS)
>> GENERIC.SETTABLE_ATTRS_ADMINISTRATOR = TestKernel, TestDoStuff,
>> TestStatusThing, $(GENERIC.SETTABLE_ATTRS_ADMINISTRATOR)
>>
>> _______________________________________________
>> HTCondor-users mailing list
>> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
>> subject: Unsubscribe
>> You can also unsubscribe by visiting
>> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
>>
>> The archives can be found at:
>> https://lists.cs.wisc.edu/archive/htcondor-users/
> 
> 
> _______________________________________________
> HTCondor-users mailing list
> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
> subject: Unsubscribe
> You can also unsubscribe by visiting
> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
> 
> The archives can be found at:
> https://lists.cs.wisc.edu/archive/htcondor-users/
>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature