<div dir="ltr"><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">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?</span><br style="font-family:arial,sans-serif;font-size:13px"><br style="font-family:arial,sans-serif;font-size:13px"></blockquote><div><br></div><div>That's correct, being a new schema it needs to be created, the access granted, and the connection URL configured in neutron.conf (doable also with devstack in the extra-conf option).</div><div> </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"><span style="font-family:arial,sans-serif;font-size:13px">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.</span><span class="im" style="font-family:arial,sans-serif;font-size:13px"><br></span><span style="font-family:arial,sans-serif;font-size:13px"></span></blockquote><div><br></div><div>That's correct too. Also, this is true for the downgrade even with a different schema.</div><div> </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"><span style="font-family:arial,sans-serif;font-size:13px">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?</span></blockquote><div><br></div><div>That should not be the case. We are not using a separate DB connection. The connection is in fact the same, the only thing that changes is the schema.</div><div>For the sql engine this should be only a matter of namespacing (different schema -> different namespace), therefore I don't see any relevant performance/connection/greenthread issue.</div><div>However I'm no DBMS expert, any additional feedback on this matter is welcome.</div><div><br></div><div>Ivar.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 10, 2014 at 2:59 PM, Robert Kukura <span dir="ltr"><<a href="mailto:kukura@noironetworks.com" target="_blank">kukura@noironetworks.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>
<div>On 10/7/14 6:36 PM, Ivar Lazzaro wrote:<br>
</div>
<blockquote 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></span>
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.<span class=""><br>
<blockquote 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></span>
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<div><div class="h5"><br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Thanks,</div>
<div>Ivar.</div>
<div><br>
</div>
<div><span>[0] <a href="https://review.openstack.org/#/c/126383/" target="_blank">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 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>
<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>
<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>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Oct 4, 2014 at 8:54
AM, Henry Gessau <span dir="ltr"><<a 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 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 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 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>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<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>
</pre>
</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>