<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>