On 10/7/14 6:36 PM, Ivar Lazzaro wrote:
I posted a patch that implements the "Different DB Different Chain"
approach [0].
That does not mean that this approach is the chosen one! It's just to
have a grasp of what the change looks like.
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.
One thing I'm particularly interested about is to hear packagers
opinions about which approach would be the preferred one: Same DB or
Different?
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?
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.
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?
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?
-Bob
Thanks,
Ivar.
[0] https://review.openstack.org/#/c/126383/
On Mon, Oct 6, 2014 at 11:09 AM, Ivar Lazzaro <ivarlazz...@gmail.com
<mailto:ivarlazz...@gmail.com>> wrote:
I believe Group-based Policy (which this thread is about) will
use the Neutron
database configuration for its dependent database.
If Neutron is configured for:
connection = mysql://user:pass@locationX:3306/neutron
then GBP would use:
connection = mysql://user:pass@locationX:3306/neutron_gbp
That's correct, that would be the likely approach if we go with
the "different schema" route.
if you can get the “other database” to be accessible from the
target database via “otherdatabase.sometable”, then you’re in.
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.
I'm experimenting this approach with our code and it seems to be
the case. '
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.
On Sat, Oct 4, 2014 at 8:54 AM, Henry Gessau <ges...@cisco.com
<mailto:ges...@cisco.com>> wrote:
Clint Byrum <cl...@fewbar.com <mailto:cl...@fewbar.com>> wrote:
>
> Excerpts from Mike Bayer's message of 2014-10-04 08:10:38 -0700:
>>
>> On Oct 4, 2014, at 1:10 AM, Kevin Benton <blak...@gmail.com
<mailto:blak...@gmail.com>> wrote:
>>
>>> 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.
>>
>> cross “database” is not typically portable, but cross
“schema” is.
>>
>> different database vendors have different notions of
“databases” or “schemas”.
>>
>> if you can get the “other database” to be accessible from
the target database via “otherdatabase.sometable”, then you’re in.
>>
>> 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.
>>
>
> All true, however, there are zero guarantees that databases
will be
> hosted on the same server, and typically permissions are
setup to prevent
> cross-schema joins.
I believe Group-based Policy (which this thread is about) will
use the Neutron
database configuration for its dependent database.
If Neutron is configured for:
connection = mysql://user:pass@locationX:3306/neutron
then GBP would use:
connection = mysql://user:pass@locationX:3306/neutron_gbp
> Typically we use the public API's when we want to access
data in a
> different application. The database is a private
implementation detail
> of each application.
Currently GPB is very tightly coupled to Neutron.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
