On Nov 1, 2012, at 8:49 AM, Matthew Farrellee <matt@xxxxxxxxxx> wrote:
> On 11/01/2012 09:13 AM, Brian Bockelman wrote:
>>
>> On Nov 1, 2012, at 7:03 AM, Matthew Farrellee <matt@xxxxxxxxxx> wrote:
>>
>>> On 10/31/2012 08:40 AM, Brian Bockelman wrote:
>>>>
>>>> On Oct 31, 2012, at 7:28 AM, Matthew Farrellee <matt@xxxxxxxxxx> wrote:
>>>>
>>>>> On 10/30/2012 06:18 PM, Brian Bockelman wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'd like to propose a few packaging changes in the various Condor distributions:
>>>>>>
>>>>>> 1) Deprecate condor_config.local. Put BIG WARNING TEXT at the top of
>>>>>> the shipped file warning site admins to not use it. The preferred
>>>>>> mechanism would be /etc/condor/config.d/99-local.config.
>>>>>> - This will better align UW HTCondor with OSG, Fedora, and RHEL distributions.
>>>>>
>>>>> The Red Hat distribution does not include a functional
>>>>> condor_config.local. The file does exist under
>>>>> /usr/share/doc/.../examples/.
>>>>>
>>>>> Additionally, we put a BIG WARNING TEXT at the top of
>>>>> /etc/condor/condor_config that says not to edit
>>>>> /etc/condor/condor_config and instead to use /etc/condor/config.d/
>>>>> [0].
>>>>>
>>>>
>>>> Yes - long-term, I'd like to get everything to that point.
>>>
>>> +1
>>>
>>>
>>>>>> 2) Add BIG WARNING TEXT to any config file that is automatically
>>>>>> overwritten (I'm looking at you, 00personal_condor and 60qmf).
>>>>>
>>>>> You mean package owned configuration files? I'd go further and say
>>>>> they should be read-only, maybe even immutable. Same goes for
>>>>> /etc/condor/condor_config.
>>>>>
>>>>
>>>> This has the same problem as the condor_config.local: upgrades of
>>>> existing sites. I don't want to clobber folks who use this on
>>>> upgrade.
>>>
>>> +1
>>>
>>>
>>>>>> 3) In the manual, document that the "end-user namespace" of config.d
>>>>>> are things which start with the "90" prefix; 00 through 59 are
>>>>>> reserved for core Condor and 60 through 89 are reserved for
>>>>>> distributors / contrib modules. Best to define this ASAP to allow
>>>>>> for maximum flexibility in future work.
>>>>>
>>>>> We provide guidance on how to name files under /etc/condor/config.d/ -
>>>>>
>>>>> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_MRG/2/html-single/Grid_User_Guide/index.html#chap-Grid_User_Guide-Configuration
>>>>>
>>>>> To ensure the files are ordered correctly, each filename is preceded with a two-digit number, using the following ranges:
>>>>> 00 - personal condor (included by default)
>>>>> 10-40 - user configuration files
>>>>> 50-80 - Package owned configuration files
>>>>> 99 - Reserved for wallaby
>>>>>
>>>>> A guiding principal is that package owned configuration files should only extend existing configuration in a way that allows for proper function of the features provided by the package.
>>>>>
>>>>> For instance, 60condor-qmf.config will provide JOB_SERVER, JOB_SERVER_LOG and extend SCHEDD.PLUGINS via "$(SCHEDD.PLUGINS) $(LIB)/...plugin.so".
>>>>>
>>>>> Under our scheme, 99-local.config would be 10local.config.
>>>>>
>>>>
>>>> This seems backwards. We want users to be able to override the
>>>> package configs.
>>>
>>> Is that desire to override because the condor-qmf.config goes too far or because you want packaged configs to commonly go beyond things like JOB_SERVER=/usr/sbin... & JOB_SERVER_LOG = $(LOG)... ?
>>>
>>
>> In the case of condor-qmf, it goes too far.
>>
>> However, I cannot guarantee that the settings I provide for a package are always correct! Maybe someone really, really wants to move JOB_SERVER_LOG somewhere strange.
>>
>> Other packages, like glideinWMS, have configuration decisions which aren't quite as straightforward.
>>
>>>
>>>> The 60condor-qmf.config has been highly problematic for us: if you
>>>> install the package, there's no way to remove JOB_SERVER from the
>>>> daemon list. I think that goes separating package installation from
>>>> enabling services.
>>>
>>> I must admit this is an inconsistency. The config there goes beyond not getting in the way, all the way to "installed thus enabled".
>>>
>>> This has not been a significant problem with our install base, because the use of wallaby for config management sits at position 99 and takes control of the DAEMON_LIST.
>>>
>>
>> Yeah - "plain" Condor configuration provides no equivalent to:
>>
>> DAEMON_LIST =- JOB_SERVER
>>
>> It's always additive!
>>
>> Anyhow, I would say we reserve 99 for "site administrators or the
>> site configuration management tools". How's that?
>
> +1 escape catch / expert zone
>
> The leaves us with -
>
> 00 - personal condor (works out of the box)
> 10-40 - user configurations
> 50-80 - package owned configurations
> 99 - override zone / escape hatch or, sure, "site administrators or site configuration management tools"
>
>
Ahem,
The point of bringing up this thread was to align RH+others best practices with UW best practices to prevent confusion. Any UW folks have thoughts on the subject?
Brian
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}