<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 10/7/14 6:36 PM, Ivar Lazzaro wrote:<br>
</div>
<blockquote
cite="mid:CAGapyGcbUj7KTNniUBTdheK7_HyOXYSC4DVb4qMOV+v9AeOhAQ@mail.gmail.com"
type="cite">
<div dir="ltr">I posted a patch that implements the "Different DB
Different Chain" approach [0].
<div>That does not mean that this approach is the chosen one!
It's just to have a grasp of what the change looks like. </div>
<div><br>
</div>
<div>The "Same DB different chain" solution is much simpler to
implement (basically you just specify a different version
table in the alembic environment) so I haven't posted anything
for that.</div>
<div><br>
</div>
<div>One thing I'm particularly interested about is to hear
packagers opinions about which approach would be the preferred
one: Same DB or Different?</div>
</div>
</blockquote>
It seems to me that deployment tools such as puppet scripts would
also be simpler if the GBP service plugin used the neutron DB, as
there would be no need to create a separate DB, set its permissions,
put its URL into neutron's config file, etc.. All that would be
needed at deployment time is to run the additional gbp-db-manage
tool to perform the GBP DB migrations. Am I missing anything?<br>
<br>
With dependencies only in one direction, and the foreign keys GBP
depends on (neutron resource IDs) unlikely to be changed by neutron
migrations during Kilo, I don't think we need to worry about
interleaving GBP migrations with neutron migrations. On initial
deployments or version upgrades, it should be sufficient to run
gbp-db-manage after neutron-db-manage. On downgrades, some
situations might require running gbp-db-manage before
neutron-db-manage. This seems not to be effected by whether the two
migration chains are in the same DB/schema or different ones.<br>
<blockquote
cite="mid:CAGapyGcbUj7KTNniUBTdheK7_HyOXYSC4DVb4qMOV+v9AeOhAQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Also, on the line of Bob's comment in my patch, is there
any kind of compatibility or performance issue anyone is aware
of about in using cross schema FKs?</div>
</div>
</blockquote>
In addition to compatibility and performance, I'm also concerned
about DB connection management when the same server is using
multiple connection URLs. I'm not convinced the approach in the
patch is sufficient. At least with some DBs, wouldn't we we need a
separate sqlalchemy.create_engine() call with each DB's connection
URL, which might require using separate context and session objects
rather than the ones neutron uses?<br>
<br>
-Bob<br>
<blockquote
cite="mid:CAGapyGcbUj7KTNniUBTdheK7_HyOXYSC4DVb4qMOV+v9AeOhAQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Thanks,</div>
<div>Ivar.</div>
<div><br>
</div>
<div><span>[0] <a moz-do-not-send="true" class="linkclass"
href="https://review.openstack.org/#/c/126383/">https://review.openstack.org/#/c/126383/</a></span></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Oct 6, 2014 at 11:09 AM, Ivar
Lazzaro <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ivarlazzaro@gmail.com" target="_blank">ivarlazzaro@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px
0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span
style="font-family:arial,sans-serif;font-size:13px">I
believe Group-based Policy (which this thread is
about) will use the Neutron</span><br
style="font-family:arial,sans-serif;font-size:13px">
<span
style="font-family:arial,sans-serif;font-size:13px">database
configuration for its dependent database.</span><br
style="font-family:arial,sans-serif;font-size:13px">
<br
style="font-family:arial,sans-serif;font-size:13px">
<span
style="font-family:arial,sans-serif;font-size:13px">If
Neutron is configured for:</span><br
style="font-family:arial,sans-serif;font-size:13px">
<span
style="font-family:arial,sans-serif;font-size:13px">
connection = mysql://user:pass@locationX:</span><span
style="font-family:arial,sans-serif;font-size:13px">3306/neutron</span><br
style="font-family:arial,sans-serif;font-size:13px">
<span
style="font-family:arial,sans-serif;font-size:13px">then
GBP would use:</span><br
style="font-family:arial,sans-serif;font-size:13px">
<span
style="font-family:arial,sans-serif;font-size:13px">
connection = mysql://user:pass@locationX:</span><span
style="font-family:arial,sans-serif;font-size:13px">3306/neutron_gbp</span></blockquote>
<div><br>
</div>
</span>
<div>That's correct, that would be the likely approach if
we go with the "different schema" route.</div>
<span class="">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px
0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div
style="font-family:arial,sans-serif;font-size:13px">if
you can get the “other database” to be accessible
from the target database via
“otherdatabase.sometable”, then you’re in.</div>
<div
style="font-family:arial,sans-serif;font-size:13px">from
SQLAlchemy’s perspective, it’s just a name with a
dot. It’s the database itself that has to support
the foreign key at the scope you are shooting for.</div>
</blockquote>
<div><br>
</div>
</span>
<div>I'm experimenting this approach with our code and it
seems to be the case. '</div>
<div>I feel that having the constraint of pointing the
same database connection with a different schema is
pretty acceptable given how tight is GBP to Neutron.</div>
<div> </div>
</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Oct 4, 2014 at 8:54
AM, Henry Gessau <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:gessau@cisco.com" target="_blank">gessau@cisco.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Clint
Byrum <<a moz-do-not-send="true"
href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>>
wrote:<br>
><br>
> Excerpts from Mike Bayer's message of
2014-10-04 08:10:38 -0700:<br>
>><br>
>> On Oct 4, 2014, at 1:10 AM, Kevin
Benton <<a moz-do-not-send="true"
href="mailto:blak111@gmail.com"
target="_blank">blak111@gmail.com</a>>
wrote:<br>
>><br>
>>> Does sqlalchemy have good support
for cross-database foreign keys? I was under the
impression that they cannot be implemented with
the normal syntax and semantics of an
intra-database foreign-key constraint.<br>
>><br>
>> cross “database” is not typically
portable, but cross “schema” is.<br>
>><br>
>> different database vendors have
different notions of “databases” or “schemas”.<br>
>><br>
>> if you can get the “other database” to
be accessible from the target database via
“otherdatabase.sometable”, then you’re in.<br>
>><br>
>> from SQLAlchemy’s perspective, it’s
just a name with a dot. It’s the database
itself that has to support the foreign key at
the scope you are shooting for.<br>
>><br>
><br>
> All true, however, there are zero
guarantees that databases will be<br>
> hosted on the same server, and typically
permissions are setup to prevent<br>
> cross-schema joins.<br>
<br>
</span>I believe Group-based Policy (which this
thread is about) will use the Neutron<br>
database configuration for its dependent database.<br>
<br>
If Neutron is configured for:<br>
connection =
mysql://user:pass@locationX:3306/neutron<br>
then GBP would use:<br>
connection =
mysql://user:pass@locationX:3306/neutron_gbp<br>
<span><br>
> Typically we use the public API's when we
want to access data in a<br>
> different application. The database is a
private implementation detail<br>
> of each application.<br>
<br>
</span>Currently GPB is very tightly coupled to
Neutron.<br>
<div>
<div><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">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>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</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>