<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 2/6/2013 10:26 AM, Anne Gentle
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAD0KtVHirw=ucUffkdzKqrZavf5ncXemA=ERyAewRkdCWmxW0A@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <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
                moz-do-not-send="true" 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>
    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>
    <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>
  </body>
</html>