Re: [HTCondor-users] Do you NEED to share condor_config across multiple versions of HTCondor?

[Brian Candler <b.candler@xxxxxxxxx>]

> 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
Funky+new-Syntax
#endif

(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.

Regards,

Brian.