Ubuntu system image

Bug #1373467
Comment #1

Comment 1 for bug 1373467

Revision history for this message

Barry Warsaw (barry) wrote on 2014-10-03: Re: Ability to specify alternate client.ini

Here's some thinking on the idea. Rather than completely obsolete client.ini and channel.ini, I'm thinking about the following rules:

1) /etc/system-image/client.ini is loaded first if it exists

2) /etc/system-image/config.d/ is scanned for files ending in .ini or .cfg, and sorted alphanumerically by file name

3) the matching, sorted config.d/ files are loaded, and can override anything in client.ini

4) /etc/system-image/channel.ini is loaded, which currently allows overriding only the [service] section.

Now, questions:

* Should we retain /etc/system-image/client.ini or just move all ini files to config.d? If we move it, it should probably be named /etc/system-image/config.d/00_default.ini.

* Should we keep the --config/-C option? Right now it names an alternative client.ini file and this is used by the test suite among other use cases. Maybe we should just change this so that it names the config.d/ directory.

* If we keep the default client.ini location, should we allow it to specify where it's config.d/ directory is?

* Should we keep channel.ini? We could theoretically just move it to config.d/ and name it something like 01_channel.ini.

* Should we lift the override restriction on channel.ini and just treat that file the same as all the others, i.e. allowing it to override any setting in any section? This will require coordination with image builds since channel.ini is generated by that process. If we move it we might need a transition period.

* Is alphanumeric sorting good enough? An alternative is to require a regexp like (?P<order>\d+)_[.*].(cfg|ini) and sort only on the int() conversion of 'order'.

I'm pretty sure I can do the simple cases with just the stdlib configparser. Another implementation choice might be lazr.config, which has some very nice properties, but isn't even in main, and I'm reluctant to do a MIR for it unless it's really necessary. (Side note, I've been thinking about pulling some of the nicer features of lazr.config into the stdlib for Python 3.5.)

I may have more questions once I start to implement this. I'm really tempted to replace client.ini and channel.ini and lift the override restrictions.

Here's some thinking on the idea.  Rather than completely obsolete client.ini and channel.ini, I'm thinking about the following rules:

1) /etc/system-image/client.ini is loaded first if it exists

2) /etc/system-image/config.d/ is scanned for files ending in .ini or .cfg, and sorted alphanumerically by file name

3) the matching, sorted config.d/ files are loaded, and can override anything in client.ini

4) /etc/system-image/channel.ini is loaded, which currently allows overriding only the [service] section.

Now, questions:

* Should we retain /etc/system-image/client.ini or just move all ini files to config.d?  If we move it, it should probably be named /etc/system-image/config.d/00_default.ini.

* Should we keep the --config/-C option?  Right now it names an alternative client.ini file and this is used by the test suite among other use cases.  Maybe we should just change this so that it names the config.d/ directory.

* If we keep the default client.ini location, should we allow it to specify where it's config.d/ directory is?

* Should we keep channel.ini?  We could theoretically just move it to config.d/ and name it something like 01_channel.ini.

* Should we lift the override restriction on channel.ini and just treat that file the same as all the others, i.e. allowing it to override any setting in any section?  This will require coordination with image builds since channel.ini is generated by that process.  If we move it we might need a transition period.

* Is alphanumeric sorting good enough?  An alternative is to require a regexp like (?P<order>\d+)_[.*].(cfg|ini) and sort only on the int() conversion of 'order'.

I'm pretty sure I can do the simple cases with just the stdlib configparser.  Another implementation choice might be lazr.config, which has some very nice properties, but isn't even in main, and I'm reluctant to do a MIR for it unless it's really necessary.  (Side note, I've been thinking about pulling some of the nicer features of lazr.config into the stdlib for Python 3.5.)

I may have more questions once I start to implement this.  I'm really tempted to replace client.ini and channel.ini and lift the override restrictions.