[nova][kolla] questions on cells
melanie witt
melwittt at gmail.com
Wed Oct 2 20:09:24 UTC 2019
On 9/30/19 8:14 PM, melanie witt wrote:
> On 9/30/19 12:08 PM, Matt Riedemann wrote:
>> On 9/30/2019 12:27 PM, Dan Smith wrote:
>>>> 2. Do console proxies need to live in the cells? This is what devstack
>>>> does in superconductor mode. I did some digging through nova code, and
>>>> it looks that way. Testing with novncproxy agrees. This suggests we
>>>> need to expose a unique proxy endpoint for each cell, and configure
>>>> all computes to use the right one via e.g. novncproxy_base_url,
>>>> correct?
>>> I'll punt this to Melanie, as she's the console expert at this point,
>>> but I imagine you're right.
>>>
>>
>> Based on the Rocky spec [1] which says:
>>
>> "instead we will resolve the cell database issue by running console
>> proxies per cell instead of global to a deployment, such that the cell
>> database is local to the console proxy"
>>
>> Yes it's per-cell. There was stuff in the Rock release notes about
>> this [2] and a lot of confusion around the deprecation of the
>> nova-consoleauth service for which Mel knows the details, but it looks
>> like we really should have something documented about this too, here
>> [3] and/or here [4].
>
> To echo, yes, console proxies need to run per cell. This used to be
> mentioned in our docs and I looked and found it got removed by the
> following commit:
>
> https://github.com/openstack/nova/commit/009fd0f35bcb88acc80f12e69d5fb72c0ee5391f
>
>
> so, we just need to add back the bit about running console proxies per
> cell.
FYI I've proposed a patch to restore the doc about console proxies for
review:
https://review.opendev.org/686271
-melanie
>> [1]
>> https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/convert-consoles-to-objects.html
>>
>> [2] https://docs.openstack.org/releasenotes/nova/rocky.html
>> [3] https://docs.openstack.org/nova/latest/user/cellsv2-layout.html
>> [4]
>> https://docs.openstack.org/nova/latest/admin/remote-console-access.html
>>
>
More information about the openstack-discuss
mailing list