[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HTCondor-users] Do you NEED to share condor_config across multiple versions of HTCondor?
- Date: Thu, 09 Jan 2014 20:26:47 +0000
- From: Brian Candler <b.candler@xxxxxxxxx>
- Subject: Re: [HTCondor-users] Do you NEED to share condor_config across multiple versions of HTCondor?
> I don't see why we can't have a versioning scheme for configuration
files, as it seems like a far more productive venture, and would enable
shifts over time.
If I understand correctly, what's proposed is that in htcondor version
N+1 you can turn on some feature X, which makes no sense to version N
(it can't even be parsed).
I don't think a versioning scheme for entire config files helps very
much. You can't expect version N to read an N+1 config file since you
can't predict future changes in syntax. What you could have is
conditional sections like
#if VERSION >= 8.2.0
(of course, that in itself would be a new syntax feature which would
confuse older versions).
But even then, the best you can expect is that version N can ignore
feature X if it is requested in the config. Is that reasonable? In other
words, if the manager configures feature X, is it OK to silently ignore
this? What if that feature is essential for correct behaviour of the
If you have a mixture of nodes running versions N and N+1, it seems to
me that you can:
1. Not make use of feature X
2. Enable feature X on the N+1 nodes only (by pushing out different
configs to those nodes)
3. Upgrade all your nodes to N+1 before enabling feature X
Seems pretty reasonable to me.