<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 08/01/2013 11:40 AM, Dolph Mathews
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAC=h7gUsRn0qXeSUNho3405Xug_Qhdz5z5pO78iqRdCydNGkCA@mail.gmail.com"
      type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra">
          <div class="gmail_quote">On Wed, Jul 31, 2013 at 5:00 AM,
            Henry Nash <span dir="ltr"><<a moz-do-not-send="true"
                href="mailto:henryn@linux.vnet.ibm.com" target="_blank">henryn@linux.vnet.ibm.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Adam,<br>
              <br>
              Wanted to just give you more detail on the issue I keep
              pressing on for your change (<a moz-do-not-send="true"
                href="https://review.openstack.org/#/c/36731/"
                target="_blank">https://review.openstack.org/#/c/36731/</a>).<br>
              <br>
              For extensions which create their own "private" tables, I
              totally get it.  I'd like, however, to understand what
              happens for a more complex extension.  Let's imagine an
              (only-partially) hypothetical example of an extension that
              does (all of) the following:<br>
              <br>
              1) It adds or changes the use of some columns in existing
              core tables, and has migrations and code that goes along
              with that.<br>
              2) It adds a new "private" table, and has all the code to
              handle that<br>
            </blockquote>
            <div><br>
            </div>
            <div>I see the need for quotations here as a big red flag:
              what exactly is the use case we're solving for? The quotes
              imply to me that we're simply moving code around within
              the git repo as a refactor with no real gain.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    The code in question was a table that linked endpoints to projects. 
    This won't flay, as both endpoints nad projects are in separate
    backends.  Theoretically, both could come from a backing store other
    than SQL.  The solution to this particular problem is:<br>
    <br>
    As an extension, put it in a table with values to that point to the
    public IDs for endspoints and projects.<br>
    xor<br>
    Make the table part of the assignments backend, and give it a fk
    constraint to proejcts<br>
    xor<br>
    Make the table part of the catalog backend and give it a fk
    constraint to endpoints.<br>
    <br>
    As it is going in as an extension, it has to be the first option.<br>
    <br>
    <br>
    <br>
    <blockquote
cite="mid:CAC=h7gUsRn0qXeSUNho3405Xug_Qhdz5z5pO78iqRdCydNGkCA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>If the goal is to allow an extension to back to some
              sql store that is not shared by the rest of keystone
              (which is I thought how this conversation started?), then
              I'm not clear on how separate migration repos would be the
              first step in that direction. If the extension owns it's
              own sql store and therefore it's sqlalchemy engine, only
              then does it makes sense (to me) to bundle the extension
              with it's own migration repo. That would make "private"
              tables <i>actually </i>private, given that they'd be
              configurable with unique sqlalchemy connection strings,
              etc.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    What it does it splits the migration version for the extension from
    the rest of Keystone.  We could drop the Endpoint table all
    together, but the endpoint-filtering plugin would still work.  Core
    tables don't care about extensions.<br>
    <br>
    It will also greatly reduce the rebase ovehead of database
    migrations patches.<br>
    <br>
    My patch does run the migrations for all extension, but it does not
    have to do so.  It might make sense, either as part of this patch or
    as a follow on, to provide command line switches to show the set of
    extensions that have repos, and to show the versions of those
    extensions in the database pointed to by the connection string. 
    There is another blueprint for supporting multiple SQL sources, and,
    with that, we could potentially map extension to different databases
    than the core repo.  We can also add a command line parameter that
    explicitly specifies the extension for which to run the migrations.<br>
    <br>
    <br>
    <blockquote
cite="mid:CAC=h7gUsRn0qXeSUNho3405Xug_Qhdz5z5pO78iqRdCydNGkCA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              3) New APIs etc. to create new REST calls to drive the
              extension<br>
              <br>
              It is part 1) in the above that I am trying to understand
              how we would implement in this new model.  What I am
              imagining is that the best way to do 1) is that you would
              break (at least part of it) out of the extension and it
              would be a core patch.  This would cover modifications to
              core columns and changing any core code to make sure that
              such changes were benign to the rest of core (and indeed
              any other extensions).  Migrations for this part of the
              schema change would be in the core repo.  Our new
              extension would then build on this, have its private new
              table in its own repo and any unique code in contrib. Is
              that how you imagined this working?<br>
              <br>
              This hypothetical example is, of course, not too far from
              reality - the recent change I did for  inherited roles (<a
                moz-do-not-send="true"
                href="https://review.openstack.org/#/c/35986/"
                target="_blank">https://review.openstack.org/#/c/35986/</a>)
              is an example that comes close to the above - and it would
              seem to me that it would be much safer (from a code
              dependency point of view) to have the DB changes done
              separately and integrated into core - and the extensions
              just, in this case, use the advantages of the new schema
              to provide its functionality.<br>
              <br>
              Henry<br>
              <br>
              <br>
              _______________________________________________<br>
              OpenStack-dev mailing list<br>
              <a moz-do-not-send="true"
                href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
              <a moz-do-not-send="true"
                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>
            </blockquote>
          </div>
          <br>
          <br clear="all">
          <div><br>
          </div>
          -- <br>
          <div><br>
          </div>
          -Dolph
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>