On 07/28/2016 02:10 PM, Chris Dent wrote:
On Thu, 28 Jul 2016, Jay Pipes wrote:
* There was some discussion of adding a configuration setting (e.g.
'placement_connection') that if not None (the default) would be
used as the connection for the placement database. If None, the
API database would be used. I can't recall if we said 'yea' or
'nay' to this idea. The current code uses the api database and its
config.
The decision at the mid-cycle was to add a new
placement_sql_connection configuration option to the nova.conf. The
default value would be None which would mean the code in
nova/objects/resource_provider.py would default to using the API
database setting.
Roger that. I was pretty sure that was what we decided but wanted to
confirm as unless I'm mistaken it is a considerable change.
As I understand things it means:
* integrating however much of Roman's WIP at
https://review.openstack.org/#/c/342384/ is required (we need our
own copies of the models and migrations and a manage script to do
a db-sync, yes?)
* adding the config setting
* doing the creation of the correct transaction context dependent on
that config
* adding the new db into the existing nova.fixtures so the tests can work
* reno note
The above matches my understanding and expectations, yes.
Do we want to test against both configurations?
Not sure. If you're asking whether we should have separate gate jobs
that pass None and a not-None-not-same-as-API-DB value for
placement_sql_connection, I don't think that's necessary. A single
functional test that sets placement_sql_connection to a
not-None-not-API-DB value and verifies that data is written to a
database other than the API database would be acceptable to me.
# less straightforward and further out things
[snip]
This will be in Ocata.
Sorry if I wasn't clear about this. By "further out" I meant "not
newton". I'll spin off an adjacent thread to deal with any followups
on these parts. I think it is useful to keep the conversation
flowing on these topics, especially after all the input and
discussion at the mid-cycle.
Ack, and thanks :)
Best,
-jay
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
