[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: Fri, 10 Jan 2014 10:59:29 -0600
- From: "John (TJ) Knoeller" <johnkn@xxxxxxxxxxx>
- Subject: Re: [HTCondor-users] Do you NEED to share condor_config across multiple versions of HTCondor?
This is a good summary/restatement of the issue.
Also, I like the #if VERSION idea, that would make future syntax
changes/improvements less of an issue.
On 1/9/2014 2:26 PM, Brian Candler wrote:
> 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 application?
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.
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx
You can also unsubscribe by visiting
The archives can be found at: