Feature #8437

Split entry configuration from main factory config

Added by Parag Mhashilkar almost 5 years ago. Updated about 4 years ago.

Configuration Management
Target version:
Start date:
Due date:
% Done:


Estimated time:




Jeff made the changes. Need to be reviewed and integrated into main code base.

From: Jeffrey Dost 
Subject: factory config mods, entries.d
Date: April 23, 2015 at 2:11:08 PM CDT
To: Parag Mhashilkar

Hi Parag,

I've finished an implementation that gives me everything we need to start hosting our factory configs in git, to better share between factories.

As a high level overview things changed
- striped out all usage of cgWParams.GlideinParams.  I replaced this xml "parser" in favor of just straight xml.dom.minidom parsing, and added a small utility library factXmlUtil that has some helper functions.
- removed schedd_name references in xml file.  This was the only thing in the entries that is factory specific since it had the host names in it.
- no longer put glideinWMS.xml under internal factory "version control", instead there is only 1 config file at any given time, the one we modify, either in /etc/gwms-factory if rpm, or the *.cfg dir.
- a corollary to the above, nothing ever writes back to this xml file, we always found that annoying.  In other words, a factory reconfig won't rearrange / generate xml, etc
- added the ability to look for entries in other *.xml files located in an entries.d dir located under /etc/gwms-factory  or *.cfg, if it exists.  This allows us to split the entries into their own files however we we want.

If you'd like to review my work, find the fork in my github.  You can diff master with the jeff_rewrite_fact_xml branch to see the changes:

Let me know what's next, and if you accept my changes, what we can do next to get it pushed back into the glideinwms upstream.


Related issues

Blocks GlideinWMS - Milestone #4991: Factory/frontend configurabilityClosed11/21/2013


#1 Updated by Parag Mhashilkar almost 5 years ago

Moving this to development series. If this is ready by v3.3 it will be shipped in that version else pushed to future releases.

#2 Updated by Parag Mhashilkar almost 5 years ago

  • Target version changed from v3_2_10 to v3_3

#3 Updated by Parag Mhashilkar over 4 years ago

  • Status changed from New to Feedback
  • Assignee changed from Parag Mhashilkar to Marco Mambelli
  • Target version changed from v3_3 to v3_2_12

Original changes are in Jeff's github repo. I have pulled them into our repo under jeff_rewrite_fact_xml

git checkout branch_v3_2
git checkout -b jeff_rewrite_fact_xml
git remote add --fetch github-jeff 
git merge github-jeff/jeff_rewrite_fact_xml

#4 Updated by Marco Mambelli over 4 years ago

Feedback was discussed and the only change after the review is a wrong variable name.

Created a ticket branch, v3/8437, merged the branch tracking Jeff's changes and added the correction before merging to branch_v3_2.
We decided against a rebase of the changes to avoid confusion in case Jess decides for other changes.

#5 Updated by Marco Mambelli over 4 years ago

  • Status changed from Feedback to Resolved

#6 Updated by Marco Mambelli over 4 years ago

Changed exception handling in to be compatible w/ python 2.4

#7 Updated by Marco Mambelli over 4 years ago

  • Status changed from Resolved to Feedback

Cleaned the code to be more pep 8 compliant and to remove the pylint errors when it is not guessing the type. Reopening for feedback.

#8 Updated by Marco Mambelli over 4 years ago

  • Assignee changed from Marco Mambelli to HyunWoo Kim

Only the last commit requires feedback: ab950b6a8dd9ec59a11d060492a8feabc9ffdbda

#9 Updated by HyunWoo Kim over 4 years ago

  • Status changed from Feedback to Assigned
  • Assignee changed from HyunWoo Kim to Marco Mambelli

I have reviewed the 3 files that have changed:
1. creation/lib/
All the changes except for one are about adjusting indentations and removing unnecessary empty lines
and the only change is switching from if not A in B to if A not in B which must be equivalent.

2. creation/lib/
- most of the changes are indentations and lines
- In some, arguments are added to resolve the complaints from pylint (per Marco)
- another instance of using if A not in B
Suggestion> why don't we write a comment for def add_child, def merge_defaults and def merge
saying that omitting the second arguments in these methods will result in pylint complaints?

3. creation/reconfig_glidein
- just indentations and lines

#10 Updated by Marco Mambelli over 4 years ago

  • Status changed from Assigned to Resolved

#11 Updated by Parag Mhashilkar about 4 years ago

  • Status changed from Resolved to Closed

#12 Updated by Parag Mhashilkar over 3 years ago

Also available in: Atom PDF