Open Stack

On Fri, Nov 6, 2020 at 11:49 PM fsbiz at yahoo.com <fsbiz at yahoo.com> wrote:

> Hi folks,
>
> We're on queens release.
>
> We have just setup a 2nd region.  So, now we have two regions regionOne
> and regionTwo
>
> We had a storage cluster in regionOne. Everything works good.
> We also added another storage cluster in regionTwo and have created swift
> endpoints for this.
> Using swift API, everything works fine.  The container is properly created
> in regionOne or regionTwo as
> desired.
>
>
>
> We are also using swift as the glance backend.  We are seeing an issue
> with this for regionTwo.
> When I create an image in regionTwo, it seems like the glance storage
> backend is not properly recognizing
> the endpoint and wants to store the image in regionOne.
>
> This looks like a definite bug.
> I can work around it by overriding the endpoint using swift_store_endpoint
> but if there is a known bug
> about this issue I would rather patch it than resort to overriding the URL
> endpoint returned from "auth".
>
> Is this a known bug ?  Again, we are on the latest Queens release.
>
> thanks,
> Fred.
>
>
Hi Fred,

With these details I'm not exactly sure what the bug would be here. Glance
has no concept for availability zones or regions per se. It expects
consistent database across the deployment and multi-store not being a thing
in Queens yet, there really is no meaningful way to configure multiple
instances of the same store type. While there is no enforcement of
homogenous configuration across the Glance nodes, the storage side really
depends on it for the service to operate correctly. Forcing Glance to use
different stores with the same database will likely cause lots of confusion
and poor user experience. I'd assume that to achieve what you are looking
for you'd either need to upgrade your openstack deployment to recent
version to take advantage of the multi-store work or use separate Glance
deployments per region.

best,
Erno "jokke" Kuvaja
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201112/4060976b/attachment.html>