Project

General

Profile

Feature #3100

Dynamically creating the secondary collectors config file

Added by Igor Sfiligoi almost 7 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
High
Assignee:
Igor Sfiligoi
Category:
-
Target version:
Start date:
11/01/2012
Due date:
% Done:

0%

Estimated time:
Stakeholders:
Duration:

Description

We currently have no good way to add or remove secondary collectors, after the initial install.

This ticket proposes a method for the config.d mode, where the assumption is that (with vrey few exceptions) the partial config files are never modified by hand.

The proposal is to create a tool that creates a dedicated config file, given the range of ports to use.
Any time the admin wants to change the number of secondary collector, he just runs this tool and replaces to old config file.


Related issues

Related to GlideinWMS - Idea #2991: Shipping condor config.d files in the tarballClosed10/23/2012

History

#1 Updated by Igor Sfiligoi almost 7 years ago

The proposed name for the tool is

glidecondor_createSecCol

in the install directory.

The proposed config file is

11_gwms_secondary_collectors.config

(used a number above 10, to allow static config files to fit in the lower range)

#2 Updated by Igor Sfiligoi over 6 years ago

Could we move the secondary collectors from
01_gwms_collectors.config
into
11_gwms_secondary_collectors.config
in the template directory ASAP?

It would still be static for the time being, but would simplify the use of the templates for collector admins.

#3 Updated by Burt Holzman over 6 years ago

  • Status changed from New to Feedback
  • Assignee changed from Igor Sfiligoi to John Weigand
  • Priority changed from Normal to Low

This looks like an easy change to me -- John, is this ok? (commit:825272fa)
(This doesn't address writing the actual tool).

#4 Updated by Igor Sfiligoi over 6 years ago

We also need to change the files in the install/templates are.

Should I go ahead and do it?

#5 Updated by Burt Holzman over 6 years ago

Whoops -- had that, but didn't push it. Done now.

#6 Updated by Igor Sfiligoi over 6 years ago

I don't think that's what you want.

We need both
01_gwms_collectors.config
and
11_gwms_secondary_collectors.config

01 should have only info that's relevant to all the collectors,
while 11 should have just the info specific to the secondary collectors.

#7 Updated by Igor Sfiligoi over 6 years ago

Did the split;
commit 967c4e44611dac9d9ac30a5f87acaa87b481c9a3

#8 Updated by John Weigand over 6 years ago

I agree with Igor that we should have 2 config files for the collector:
one with the basics and the other for secondary.

However, what is it we want in the 11_* config file template
- this stub?

#################################################
# Secondary Collectors
################################################# 
#
# This file should be dynamically generated
# but is provided as a static file for simple use cases
#  

or the full blown list of n collectors?

COLLECTOR0 = $(COLLECTOR)
COLLECTOR0_ENVIRONMENT = "_CONDOR_COLLECTOR_LOG=$(LOG)/Collector0Log" 
COLLECTOR0_ARGS = -f -p 9620

COLLECTOR1 = $(COLLECTOR)
COLLECTOR1_ENVIRONMENT = "_CONDOR_COLLECTOR_LOG=$(LOG)/Collector1Log" 
COLLECTOR1_ARGS = -f -p 9621

... and on and on.

The full blown one is what appears to have been committed/pushed in branch_v2plus_3100 unless I've pulled the branch down wrong.

I can make the changes for the ini and q/a installers.

Do you want me to write the utility?
and
Do we want something similar for the schedds?

John Weigand

#9 Updated by Igor Sfiligoi over 6 years ago

Hi john.

I think having a default, static 11_* that is usable without any scripts is a good thing;
most small installs can use it (assuming we put in place reasonable defaults).

However, we also want a script that will re-create it for instances that need many more secondary schedds (e.g. CMS).
This is why the comment I put in.

As for what is expected from you:
just making sure that the current changes did not break the installation.

We know we still do not have the script... so this is just step one.
Dealing with the script will happen as an independent step (and I volunteer to do it).

PS: We have already the solution for the secondary schedds (#3101)

#10 Updated by John Weigand over 6 years ago

Igor/Burt,

If I am understanding correctly, we have agreed to have 2 config files for the collectors:
- 01_gwms for the main collector data
- 11_gmws for the secondary collectors (this will be a stub if no secondary collectors are defined on an initial install)

I have change the Condor.py to reflect this.
Can I commit that change if my assumption is true?

Also, should these changes also go in the q/a installer?

Also, in terms of doc, we really have nothing on the config.d files
or the templates that I can find.
Do we need to update our doc to reflect these?

John Weigand

#11 Updated by Igor Sfiligoi over 6 years ago

Yes, two files (with 11_* having a default of 11 secondary collectors).

The ini installer and the RPM should reflect this change.

The Q&A is not based on the config.d, so does not need to be changed (this is my understanding, anyhow).

As for docs, yes, they need to be updated, but not as part of this ticket. We need a dedicated ticket for that, as it wider than just the 2ndary collectors.

#12 Updated by John Weigand over 6 years ago

Another question... I notice that this attribute is set in the 01_gwms template:

#################################################
# We expect to have secondary collectors, so
#-- forward ads to the main collector
#-- (this is ignored by the main collector, since the address matches itself)
CONDOR_VIEW_HOST = $(COLLECTOR_HOST)

In both the q/a and ini installer, this attribute is only set when secondary
collectors are requested.

Should this be in the 11_gwms template?

John Weigand

#13 Updated by Igor Sfiligoi over 6 years ago

No, I think the right place is in 01, because it is static.
(and works well without 11_)

The 11_ file should only contain stuff that will be regenerated by the (future) dynamic-secondary-collector tool.

#14 Updated by John Weigand over 6 years ago

  • Assignee changed from John Weigand to Igor Sfiligoi

Made the following changes based on discussions on the ticket:
1. Change it back to creating a 01_gwms_collectors config for the
basic collector information.
2. Creates a stub 11_gwms_secondary_collectors config if no
secondary collectors are specified on initial install.
3. Populates the 11_gwms_secondary_collectors config when
additional secondary collectors are specfied on initial install.
4. Move the negotiator attributes into the 01_gwms_collectors config
to align it more with the templates.

branch_v2plus_3100
commit:b4a0e75cb8cde4bddf38bb5821d8e984a7786a47
Files affected:
./install/services/Condor.py

John Weigand

#15 Updated by Igor Sfiligoi over 6 years ago

  • Assignee changed from Igor Sfiligoi to John Weigand

Uhm... I guess I never really looked at what the INI installer is doing before!

Now, not sure if we should have the discussion on this ticket or not, but let me write it down anyhow.

Are you saying you are re-creating the template files during the install?
Why?
The whole idea of the templates is that they are static; no-one should ever change them... so they can be copied over at any point in time from the source.
(e.g. due to upgrades).

Any changes should go into "dynamic config files" who have completely different names (and start with a higher number).

PS: 11_gwms_secondary_collectors is an exception to the rule just because we can have a reasonable default there, and it is not easy to redefine some of the attributes in it in a different config file.

#16 Updated by John Weigand over 6 years ago

The ini installer is like the q/a EXCEPT that the questions
are answered in the ini file. It then installs/configures functional
glideinwms services just like the q/a.

The templates were created for the rpm installs and required manual
modifications. There is a ticket (https://cdcvs.fnal.gov/redmine/issues/2991)
that requests that the ini installer use the templates.

I have not gotten to that yet.

Maybe we need to discuss at out next meeting?

john weigand

#17 Updated by Igor Sfiligoi over 6 years ago

  • Status changed from Feedback to Assigned
  • Assignee changed from John Weigand to Burt Holzman

OK.
Anyhow, as said above, I don't think this should be solved in this ticket.

So, if you are OK with the INI code, I am OK with it too.

Now, who is responsible for the RPMs? We need to add 11_ to the spec file.
Burt?

#18 Updated by Igor Sfiligoi over 6 years ago

Created the tool as well:

~/glideinwms/install# ./glidecondor_createSecCol 
This tool creates the 11_gwms_secondary_collectors.config file
in the HTCondor's config.d directory

Usage:
 glidecondor_createSecCol [-useportasname] [-commonlog] <portrange>
where:
  -useportasname  - If specified, the collector logs use port numbers as names (default is starting with 0)
  -commonlog      - If specified, all secondary collectors will share the log file
  portrange       - Range of ports used by the secondary collectors to put in the config file (required)
Example:
  glidecondor_createSecCol 9620-9639

last commit:5c3d4c28aa363a102a08a2525f68c308371f4f99

#19 Updated by Burt Holzman over 6 years ago

  • Status changed from Assigned to Feedback
  • Assignee changed from Burt Holzman to Parag Mhashilkar
  • Priority changed from Low to High

#20 Updated by Parag Mhashilkar over 6 years ago

Can we please get away from using global variable, in this case config_dir. Any particular reason we need it to be global? Apart from that it looks ok.

Please merge it to master when you merge it to branch_V2plus well.

#21 Updated by Parag Mhashilkar over 6 years ago

  • Assignee changed from Parag Mhashilkar to Igor Sfiligoi

#22 Updated by Parag Mhashilkar over 6 years ago

Its matter of keeping up with best practices for the code that gets distributed to a wider set of audience through osg repos. When I review I try not to be partial to library v/s script as everything gets distributed as part of glideinwms package as a whole.

#23 Updated by Igor Sfiligoi over 6 years ago

  • Status changed from Feedback to Resolved

OK, fixed the global variable problem.

Then merged in both v2plus (9d21a5e23a8c33521bca8ed1c6a25abd9ddd978e)
and master (8affb4df4011ed11289b764ad3d460f2290ec27f).

#24 Updated by Parag Mhashilkar over 6 years ago

  • Target version changed from v2_7_x to v2_7_1

#25 Updated by Igor Sfiligoi over 6 years ago

Just added the documentation as well.

#26 Updated by Parag Mhashilkar over 6 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF