Open Stack

On Wed, Feb 6, 2013 at 3:32 PM, Caitlin Bestler <caitlin.bestler at nexenta.com
> wrote:

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

Entry points takes care of all of this. The code can live anywhere, and
each entry point gets a nice, short, unique name to use in the
configuration file. Developers can point to anything they want, and
non-developers don't have to know class names. We all win.

Doug


>
> 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.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130206/e117b403/attachment.html>