Open Stack

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