Open Stack

On 2/6/2013 10:26 AM, Anne Gentle wrote:
>
>
>
> On Wed, Feb 6, 2013 at 9:22 AM, Daniel P. Berrange 
> <berrange at redhat.com <mailto:berrange at redhat.com>> wrote:
>
>     Nova (and most other OpenStack components) have an ever increasing
>     number of configuration parameters which accept classnames.
>     Obviously, we're doing this to make it possible to plug in custom
>     implementations of various interfaces, which is great.
>
>     There are two downsides to this
>
>      - The user has to know about obscure, often undocumented, python
>        module names.
>
>
> Thanks for shining a light on this particular difficulty. While we now 
> have a sample nova.conf with descriptions, any use of and changes to 
> class names in both nova and quantum have caused headaches for users. 
> And doc bugs too.
>
>      - Any time we rename a class, or refactor code possibly deleting
>        or merging classes, we break the end config file upon upgrade.
>
>     The first point is a mere usability matter, but the second point
>     is a serious deployment issue IMHO, which can only get worse as
>     usage of OpenStack increases & people expect more stability and
>     consistency across upgrades.
>
>     Historically code changes have been pretty fast & loose config
>     parameters, arbitrarily changing them at any time for any reason.
>     AFAIK there are no formal rules defined about changing config
>     paramaters, but in some of the recent changes I've submitted
>     which involved config changes, reviewers wanted backwards compat
>     to be maintained. The result that when renaming, or obsoleting
>     existing classses we're having to keep around stubs for the old
>     classes to avoid breaking user config files. This is not a good
>     approach for long term maintainability of the codebase.
>
>     IMHO the core issue here is that by using classnames in config
>     parameters we are exposing what we (developers) generally consider
>     to be internal/private implementation details to the end user. End
>     user expectations wrt upgrades are thus restricting what we can do
>     with our internal implementations.
>
>     I don't think it is acceptable to have a situation where configuration
>     file parameters restrict what we can do in terms of re-arranging /
>     refactoring our codebase. Provided we maintain the same featureset
>     compatibility, we should be free todo any code refactoring we desire.
>
>     The only way we can do this is if we do *NOT* require the use of
>     classnames in config parameters. Instead we should treat all these
>     config parameters as being more like enumerations, and map those to
>     classnames internally
>
>
> I would completely support this and wish I had dev resources to put 
> behind the effort. Is there a group who wants to work on this?
>
> 44 isn't bad out of over 600 I might add.
>
> Let me help any way I can.
>
> Anne
>

One approach to solving this might be to just differentiate between 
configuration intended for python coders
from configuration intended for end users.

Because OpenStack is frequently used a toolkit, rather than as a 
finished product, there will be resistance to
removing the ability to explicitly name classes. If you're redirecting 
the plumbing this is useful stuff.

But I think a typical end user is about as likely to reconfigure this 
plumbing as they are to try to change the
plumbing in their own home.

So why not define a type of configuration that *must* make sense in end 
user terminology, i.e for non-plumbers.
That configuration would then be used to generate the plumbing level 
configuration. If it done correctly, the same
user-domain configuration items will still make sense even when there is 
a major upgrade to the internals.

We would track whether a given plumbing-level configuration had been 
hand-customized, and if not, regenerate
it from the user-level configuration with each new release.

I fear that just trying to redirect all configuration to be "user 
friendly" will meet with to much resistance from those
who actually need to do some custom plumbing. I think we need a solution 
that addresses both plumbers and non-plumbers.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130206/ad48c789/attachment.html>