attr filter "attrsfile" -> "file"

[Arran Cudbard-Bell]

On 9 Jan 2013, at 13:12, Phil Mayers <p.mayers at imperial.ac.uk> wrote:

> On 09/01/13 11:23, Arran Cudbard-Bell wrote:
> 
>> That's the point of making things consistent, so you don't have to
>> waste time referring to the man pages and documentation.
> 
> Just to point out: this change is not without cost. Thousands of sysadmins will have significantly more work upgrading their configs as a result. I'm all for rationalisation, but TBH you're not selling me on the cost/benefit tradeoff.

The decision was made to break configuration compatibility for 3.0. The configuration of the EAP module, LDAP and SQL have already changed significantly.

I won't claim this to be true for everyone, but from my own experience and reading posts on quite a few programming and administration blogs, one of the biggest timesinks in IT related jobs are context switches. That is, stashing your working knowledge of one very complex system, and constructing a mental model of another very complex system.

Once you've made the decision to start the upgrade work to transition to 3.0, you've already paid the price in terms of the context switch. You're going to have to refresh your knowledge of how the server works anyway, to upgrade your EAP/LDAP/SQL module configurations.

Adding a trivial copy and paste exercise to the upgrade process is not going to significantly increase the amount of effort you have to expend.

> Your choice, of course. But you shouldn't be surprised if this kind of thing significantly retards deployment of 3.0.

Ok, but we've already done lots of 'this kind of thing', that was one of the big things in 3.0.

>> Also adding a module specific prefix to 'file' is wrong. You know
>> what type of file it is by the module section it's declared in. The
>> only place this would be of use would be in a completely flat
>> namespace.
> 
> It may be "wrong" but it's what we CURRENTLY DO. Telling people "Hey we've changed our minds that thing we made you all do is now wrong" just irritates them.

It is *exactly* that kind of attitude which leads to Perl.

Big surprise, people contributing their time for free aren't *that* concerned where the project will be in 10 years, so yes, sometimes things do need to be re-done. It's not a case of 'changing minds'.

You need to refactor the configuration periodically just as you refactor the code, else it becomes an unworkable mess. Trying to insulate administrators from those changes means you end up with a system that is rediculously complex and unmaintainable.

Of course there's a compromise, if you were constatly refactoring the configuration, then you'd also make the system unmaintainable. That is why these changes only occur between major releases.


> Can we at least maintain backwards compatibility for one major version to read the old filenames? Surely it can't be that hard to have a short lookup table from the old names?

So then you take over maintence of a v3.x system and all the configurations are in this weird format and you can't really see how it works and, and...

For some modules, like sql, yes, you can write drop in blocks of config that remap the new structure to the old config item names, for something like this, no, it's pointless and adds complexity.

-Arran