<div dir="ltr">I believe Kiall MacInness took a shot at some of this earlier where you could have the DB code handle multiple backends using different names towards different sections of the configuration. We rely on this heavily under Moniker because we have different connections to different databases since the backends rely on it.<div>

<br></div><div>Please see <a href="https://review.openstack.org/#/c/19052/">https://review.openstack.org/#/c/19052/</a> for this.</div><div><br></div><div style>Endre.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2013/4/24 Gary Kotton <span dir="ltr"><<a href="mailto:gkotton@redhat.com" target="_blank">gkotton@redhat.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div class="im">
    On 04/23/2013 04:59 PM, Davanum Srinivas wrote:
    <blockquote type="cite">Mark, Gary,
      <div><br>
      </div>
      <div>i took a stab at the first option <a href="https://review.openstack.org/27345" target="_blank">https://review.openstack.org/27345</a>
        (switching from DEFAULT to DATABASE). <br>
      </div>
    </blockquote>
    <br></div>
    Thanks for the patch. Do we need to defer the common DB integration
    into Quantum until the BP for the case sensitive section is
    implemented (not sure how long this will take)?<div><div class="h5"><br>
    <br>
    <blockquote type="cite">
      <div><br>
        -- dims<br>
        <br>
        <div class="gmail_quote">
          On Tue, Apr 23, 2013 at 8:43 AM, Mark McLoughlin <span dir="ltr"><<a href="mailto:markmc@redhat.com" target="_blank">markmc@redhat.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div>On Tue, 2013-04-23 at 10:54 +0300, Gary
              Kotton wrote:<br>
              <br>
              > 3. In the current Quantum versions all of the
              database configuration<br>
              > information is under a section [DATABASE]. The common
              code moves this to<br>
              > [DEFAULT]. If possible it would be great if we could
              preserve the<br>
              > current configuration file settings. This will enable
              us to have<br>
              > smoother version upgrades. If this is not possible
              then we will need a<br>
              > migration script to update configuration files. Does
              anyone have<br>
              > thoughts on this? I would like to make changes to the
              common code to<br>
              > ensure that we can use the DATABASE section.<br>
              <br>
            </div>
            Ok, the bug outlines one option:<br>
            <br>
              <a href="https://bugs.launchpad.net/oslo/+bug/1171837" target="_blank">https://bugs.launchpad.net/oslo/+bug/1171837</a><br>
            <br>
            we move the db options to the 'database' group and make the
            group names<br>
            case insensitive as per:<br>
            <br>
              <a href="https://blueprints.launchpad.net/oslo/+spec/cfg-lowercase-groups" target="_blank">https://blueprints.launchpad.net/oslo/+spec/cfg-lowercase-groups</a><br>
            <br>
            Another option is to have get_session() in oslo take an
            sql_connection<br>
            parameter which would override CONF.sql_connection. Quantum
            would have<br>
            something like this:<br>
            <br>
              sql_opts = [<br>
                  cfg.StrOpt('sql_connection', default=None),<br>
              ]<br>
            <br>
              CONF.register_opts(sql_opts, group='DEFAULT')<br>
            <br>
              def get_session():<br>
                  if CONF.sql_connection:<br>
                      log.warn("deprecated!")<br>
                  return db_session.get_session(CONF.sql_connection)<br>
            <br>
            If the sets DATABASE.sql_connection they get a deprecation
            warning but<br>
            it still works. If they don't set DATABASE.sql_connection,
            the common DB<br>
            code just falls back to DEFAULT.sql_connection.<br>
            <br>
            Cheers,<br>
            Mark.<br>
            <div>
              <div><br>
                <br>
                _______________________________________________<br>
                OpenStack-dev mailing list<br>
                <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <div><br>
        </div>
        -- <br>
        Davanum Srinivas :: <a href="http://davanum.wordpress.com" target="_blank">http://davanum.wordpress.com</a>
      </div>
    </blockquote>
    <br>
  </div></div></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></div>