Networks for different availability zones in Horizon

Adam Harwell flux.adam at gmail.com
Wed Dec 22 13:36:05 UTC 2021


+1 from Yahoo.
We have a number of compute AZs in each of our clouds, and networks that
are specifically crafted for those AZs (mostly due to security zones). Our
users very commonly pick incompatible combinations. We have a user manual
with a table that shows valid combinations in an attempt to educate them,
but this is really something that would be better handled directly in the
tooling somehow. Maybe this kind of setup is more common than people think,
at least for large private cloud operators?

    —Adam

PS: I think routed networks may fix part of our configuration woes, but
certainly not all. I wonder if there is a sane way to link networks to AZs
like this…

On Wed, Dec 22, 2021 at 1:08 Jonathan Mills <jonmills at gmail.com> wrote:

> Thank you, Hai Wu, for raising the visibility of this issue.  We at NASA
> Goddard want to echo this sentiment wholeheartedly.  It’s a serious pain
> point!
>
> Our production OpenStack (Wallaby) cloud spans two AZs (different
> datacenters) right now, and before we’re done we may have 3 or 4 AZs.  We
> use non-overlapping VLAN-based networks in different datacenters.
> Moreover, we have different kinds of server hardware in each datacenter
> (often recycled HPC compute nodes).  We also have different Cinder storage
> backends in each datacenter.
>
> What we end up having is AZs in Nova, AZs in Neutron, AZs in Cinder, and
> Image Flavors for Glance that are rather AZ dependent (in order to best fit
> the node geometry).  We instantiate these objects with explicit AZs when
> they support it.  In the case of Neutron networks, we can use scheduler
> hints.
>
> The real crux of the problem is the end-user education though.  Because
> OpenStack clients (Horizon, OSC) are perfectly happy to let the end-user
> try to build impossible combinations.  We strongly feel that if the
> individual services aren’t going to communicate AZ data to each other via
> RPC, that the clients at least should do some kind of filtering on AZs or
> scheduler hints about AZs.  I'm not entirely sure how you'd solve this
> problem on CLI easily without RPC communication, but Horizon could
> (should?) dynamically filter the different menus as you select options:
> e.g. the first selection screen ‘Details’ has you choose an AZ. Once the
> user makes a selection there, the flavors, storage, and network options
> should adjust accordingly.
>
>
> Jonathan
>
>
> > On Dec 18, 2021, at 9:44 PM, hai wu <haiwu.us at gmail.com> wrote:
> >
> > Not using vxlan, so there's no network span across availability zones.
> > It seems there's no built-in way to configure Horizon to do so. The
> > problem with this is that sometimes if user picks the wrong network
> > and availability zone combo, the VM will end up in the wrong state.
> > This is why it would be ideal to only show available networks for the
> > availability zone that the user already picked.
> >
> > I am wondering how to modify the horizon source code to achieve this,
> > but I am not familiar with Angular, and the workflow code is pretty
> > complex for newbie ..
> >
> > On Sat, Dec 18, 2021 at 6:31 PM Sean Mooney <smooney at redhat.com> wrote:
> >>
> >> On Sat, 2021-12-18 at 13:45 -0600, hai wu wrote:
> >>> In Horizon "Launch Instance" workflow, in its 4th step of selecting
> >>> networks for the new instance, it would always show all the available
> >>> networks from all availability zones, regardless of which
> >>> "Availability Zone" got picked in 1st step of "Details".
> >>>
> >>> I tried to update some DB field for availability zone hint for the
> >>> relevant network, and that did not help.
> >>>
> >>> Any way to ensure in Horizon "Launch Instance" GUI workflow, after a
> >>> user picking one availability zone in step 1, it would only show the
> >>> related networks in that availability zone as available networks in
> >>> step 4?
> >>
> >> networks do not have any affinity to Avaiablity Zones.
> >> there is no mapping between neutron physnets and nova host aggreates
> which are use to
> >> model aviablityitz zones.
> >>
> >> when using tunneled networks like vxlan it is assuems that all hosts in
> a cloud acorss all avaiablity zones can access
> >> any tenant vxlan network. the same is also ture of vlan or flat network
> the only excption being that htey have physnet
> >> assocaited with them. physnets may not be aviable on all host but there
> is corralation between phsynets and aviaablity zones.
> >> unless you manually algin them.
> >>>
> >>
> >
>
>
> --
Thanks,
    --Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20211222/44b3aa7f/attachment.htm>


More information about the openstack-discuss mailing list