<br><br><div class="gmail_quote">On Wed, Feb 6, 2013 at 3:32 PM, Caitlin Bestler <span dir="ltr"><<a href="mailto:caitlin.bestler@nexenta.com" target="_blank">caitlin.bestler@nexenta.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div><div class="h5">
<div>On 2/6/2013 10:26 AM, Anne Gentle
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Feb 6, 2013 at 9:22 AM,
Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Nova
(and most other OpenStack components) have an ever
increasing<br>
number of configuration parameters which accept
classnames.<br>
Obviously, we're doing this to make it possible to plug in
custom<br>
implementations of various interfaces, which is great.<br>
<br>
There are two downsides to this<br>
<br>
- The user has to know about obscure, often undocumented,
python<br>
module names.<br>
<br>
</blockquote>
<div><br>
</div>
<div>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. <br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Any time we rename a class, or refactor code possibly
deleting<br>
or merging classes, we break the end config file upon
upgrade.<br>
<br>
The first point is a mere usability matter, but the second
point<br>
is a serious deployment issue IMHO, which can only get
worse as<br>
usage of OpenStack increases & people expect more
stability and<br>
consistency across upgrades.<br>
<br>
Historically code changes have been pretty fast &
loose config<br>
parameters, arbitrarily changing them at any time for any
reason.<br>
AFAIK there are no formal rules defined about changing
config<br>
paramaters, but in some of the recent changes I've
submitted<br>
which involved config changes, reviewers wanted backwards
compat<br>
to be maintained. The result that when renaming, or
obsoleting<br>
existing classses we're having to keep around stubs for
the old<br>
classes to avoid breaking user config files. This is not a
good<br>
approach for long term maintainability of the codebase.<br>
<br>
IMHO the core issue here is that by using classnames in
config<br>
parameters we are exposing what we (developers) generally
consider<br>
to be internal/private implementation details to the end
user. End<br>
user expectations wrt upgrades are thus restricting what
we can do<br>
with our internal implementations.<br>
<br>
I don't think it is acceptable to have a situation where
configuration<br>
file parameters restrict what we can do in terms of
re-arranging /<br>
refactoring our codebase. Provided we maintain the same
featureset<br>
compatibility, we should be free todo any code refactoring
we desire.<br>
<br>
The only way we can do this is if we do *NOT* require the
use of<br>
classnames in config parameters. Instead we should treat
all these<br>
config parameters as being more like enumerations, and map
those to<br>
classnames internally<br>
</blockquote>
<div><br>
</div>
<div>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? <br>
<br>
</div>
<div>44 isn't bad out of over 600 I might add.<br>
</div>
<div><br>
</div>
<div>Let me help any way I can.<br>
<br>
Anne<br>
</div>
<div> </div>
<br>
</div>
</div>
</div>
</blockquote>
<br></div></div>
One approach to solving this might be to just differentiate between
configuration intended for python coders<br>
from configuration intended for end users.<br>
<br>
Because OpenStack is frequently used a toolkit, rather than as a
finished product, there will be resistance to<br>
removing the ability to explicitly name classes. If you're
redirecting the plumbing this is useful stuff.<br></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<br>
But I think a typical end user is about as likely to reconfigure
this plumbing as they are to try to change the<br>
plumbing in their own home.<br>
<br>
So why not define a type of configuration that *must* make sense in
end user terminology, i.e for non-plumbers.<br>
That configuration would then be used to generate the plumbing level
configuration. If it done correctly, the same<br>
user-domain configuration items will still make sense even when
there is a major upgrade to the internals. <br>
<br>
We would track whether a given plumbing-level configuration had been
hand-customized, and if not, regenerate<br>
it from the user-level configuration with each new release.<br>
<br>
I fear that just trying to redirect all configuration to be "user
friendly" will meet with to much resistance from those<br>
who actually need to do some custom plumbing. I think we need a
solution that addresses both plumbers and non-plumbers.<br>
<br>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br>