[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?

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