[nova][kolla] questions on cells

Matt Riedemann mriedemos at gmail.com
Wed Oct 2 13:48:08 UTC 2019

On 10/1/2019 5:00 AM, Mark Goddard wrote:
>>> 5. What DB configuration should be used in nova.conf when running
>>> online data migrations? I can see some migrations that seem to need
>>> the API DB, and others that need a cell DB. If I just give it the API
>>> DB, will it use the cell mappings to get to each cell DB, or do I need
>>> to run it once for each cell?
>> The API DB has its own set of migrations, so you obviously need API DB
>> connection info to make that happen. There is no fanout to all the rest
>> of the cells (currently), so you need to run it with a conf file
>> pointing to the cell, for each cell you have. The latest attempt
>> at making this fan out was abanoned in July with no explanation, so it
>> dropped off my radar at least.
> That makes sense. The rolling upgrade docs could be a little clearer
> for multi-cell deployments here.

This recently merged, hopefully it helps clarify:


>>> 6. After an upgrade, when can we restart services to unpin the compute
>>> RPC version? Looking at the compute RPC API, it looks like the super
>>> conductor will remain pinned until all computes have been upgraded.
>>> For a cell conductor, it looks like I could restart it to unpin after
>>> upgrading all computes in that cell, correct?
>> Yeah.
>>> 7. Which services require policy.{yml,json}? I can see policy
>>> referenced in API, conductor and compute.
>> That's a good question. I would have thought it was just API, so maybe
>> someone else can chime in here, although it's not specific to cells.
> Yeah, unrelated to cells, just something I wondered while digging
> through our nova Ansible role.
> Here is the line that made me think policies are required in
> conductors:https://opendev.org/openstack/nova/src/commit/6d5fdb4ef4dc3e5f40298e751d966ca54b2ae902/nova/compute/api.py#L666.
> I guess this is only required for cell conductors though?

That is not the conductor service, it's the API.




More information about the openstack-discuss mailing list