<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">On 5/25/15 10:35 PM, Armando M. wrote:<br>
    </div>
    <blockquote
cite="mid:CAK+RQeZ+Oc9MZ39WBQsaTxMayPKTejyzQDFNStMofjcuwvo1qQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On 25 May 2015 at 09:46, Mike Bayer <span
              dir="ltr"><<a moz-do-not-send="true"
                href="mailto:mbayer@redhat.com" target="_blank">mbayer@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 bgcolor="#FFFFFF" text="#000000"><span class=""> <br>
                  <br>
                  <div>On 5/25/15 12:34 PM, Armando M. wrote:<br>
                  </div>
                  <blockquote type="cite">
                    <div dir="ltr"><br>
                      <div>
                        <div><br>
                          <br>
                        </div>
                      </div>
                      <div class="gmail_extra">
                        <div class="gmail_quote">
                          <div> </div>
                          <div>One thing I would like to point out is
                            that in this cycle we'll be working
                            extensively in this area to make the very
                            task you are working on easier to deal with,
                            and better documented. This will fall under
                            the umbrella of the blueprint [1].</div>
                          <div><br>
                          </div>
                          <div>HTH</div>
                          <div>Armando</div>
                          <div><br>
                          </div>
                          <div>[1] <a moz-do-not-send="true"
href="https://blueprints.launchpad.net/neutron/+spec/core-vendor-decomposition"
                              target="_blank">https://blueprints.launchpad.net/neutron/+spec/core-vendor-decomposition</a></div>
                        </div>
                      </div>
                    </div>
                  </blockquote>
                  <br>
                </span> took a look at <a moz-do-not-send="true"
                  href="https://review.openstack.org/#/c/134680/17"
                  target="_blank">https://review.openstack.org/#/c/134680/17</a>,
                can I have some clarification on what "currently alembic
                requires extra work to support multiple db migration
                paths onto a single database"?   Want to make sure
                you're aware that Alembic supports this fully (and my
                job has been to try to get Openstack projects to
                notice); see
                <a moz-do-not-send="true"
href="http://alembic.readthedocs.org/en/latest/branches.html#working-with-multiple-bases"
                  target="_blank">http://alembic.readthedocs.org/en/latest/branches.html#working-with-multiple-bases</a>.<span
                  class=""><br>
                       </span></div>
            </blockquote>
            <div><br>
            </div>
            <div>The wording might be confusing, my bad.</div>
            <div><br>
            </div>
            <div>What I intended there was that neutron's logic to
              handle alembic migrations required some work in order to
              simplify the support of out-of-tree DB migrations. Past
              experiences, like the one that triggered this thread, have
              shown that we can improve neutron's tooling
              (neutron-db-manage), as well as documentation.</div>
          </div>
        </div>
      </div>
    </blockquote>
    I wonder if there is some way that out-of-tree migrations can still
    take place within the migration stream as a whole.  As those
    external trees can be built assuming the central Neutron migration
    series as a dependency, if their directories are added to the
    "version_locations" collection before the alembic command line
    runner invokes the migration, they will form part of the total
    migration setup for the database.   This was one use case I had in
    mind when building out this feature.   The command line runner is
    extensible so a runtime extension to configuration is feasible.<br>
    <br>
    <br>
    <br>
  </body>
</html>