Open Stack

Hi Sean,

Thanks for your input. I have an open bug report here to skyline. It would
be good if you add your point there for more visibility
https://bugs.launchpad.net/skyline-apiserver/+bug/2035012

On Mon, Sep 11, 2023 at 4:53 AM <smooney at redhat.com> wrote:

> On Sun, 2023-09-10 at 14:51 +0100, Lucas Alvares Gomes wrote:
> > On Sun, Sep 10, 2023 at 4:13 AM Satish Patel <satish.txt at gmail.com>
> wrote:
> > >
> > > Folks,
> > >
> > > I am trying to set an availability zone for OVN because skyline UI has
> a mandatory requirement to have an
> > > availability zone otherwise you are not allowed to create a network
> from skyline GUI.
> one thing that skiline and admin s to a lesser degree need to be aware of
> is that nova AZ, Neutron AZ and cinder AZ
> are generally not related to each other. you as an admin can align them
> but a enduser should not assume that
> when creating a vm with a netwok and a voluem that the name of the AZ for
> all 3 should be the same.
> AZs are also optional in all 3 servics that support them. nova invents a
> fake AZ called "nova" and puts all host
> that dont otherwise have an az in it but its considerd a bug to explictly
> request the nova az.
> we have debated makeing that a hard error in future api version although
> currently we do know that some people do
> reueqst the defautl nova az even though we document that you should not.
> https://docs.openstack.org/nova/latest/admin/availability-zones.html
> """
> The use of the default availability zone name in requests can be very
> error-prone. Since the user can see the list of
> availability zones, they have no way to know whether the default
> availability zone name (currently nova) is provided
> because a host belongs to an aggregate whose AZ metadata key is set to
> nova, or because there is at least one host not
> belonging to any aggregate. Consequently, it is highly recommended for
> users to never ever ask for booting an instance
> by specifying an explicit AZ named nova and for operators to never set the
> AZ metadata for an aggregate to nova. This
> can result is some problems due to the fact that the instance AZ
> information is explicitly attached to nova which could
> break further move operations when either the host is moved to another
> aggregate or when the user would like to migrate
> the instance.
> """
>
> i raise this because i would consider it a bug form a nova point of view
> if skyline forced you to specyify
> an az when booting a vm. i would also consider it a bug in skyline if it
> forced the same on neutron or cinder
> since they are an optional feature. even if its common to configure them
> the skyline ui should not force you to select
> one.
>
>
> > >
> > > for OVN based deployment only option to set AZ is in ovn-cms-options
> > >
> > > # ovs-vsctl set open_vswitch .
> external_ids:ovn-cms-options="enable-chassis-as-gw,availability-zones=az-0"
> > >
> > > Question:
> > >
> > > 1. How do I configure in kolla-ansible to override or set
> ovn-cms-options on only gateway chassis?
> > > 2. How does AZ work in OVN because OVN is anyway distributed as per
> documents, What if I just give foobar AZ name to
> > > meet Skyline requirement? Is it going to break anything?
> >
> > Answering 2.
> >
> > There are two types of availability zones in Neutron: Routers and
> Networks.
> >
> > For Routers, ML2/OVN will schedule the gateway router ports onto the
> > nodes belonging to the availability zones provided by the
> > --availability-zone-hint parameter, for example:
> >
> > $ openstack router create --availability-zone-hint az-0
> > --availability-zone-hint az-1 router-0
> >
> > For Networks. Since DHCP is distributed in ML2/OVN as you pointed out
> > we do not care about scheduling DHCP agents (like ML2/OVS). But there
> > are few cases for Network AZ in ML2/OVN that are related to external
> > ports [0], these are ports that live on a different host than the
> > instance to address use cases such as SR-IOV and Baremetal with
> > ML2/OVN.
> >
> > You can read more ML2/OVN AZs here:
> >
> https://docs.openstack.org/neutron/latest/admin/ovn/availability_zones.html
> >
> > [0]
> https://docs.openstack.org/neutron/latest/admin/ovn/external_ports.html
> >
> > Cheers,
> > Lucas
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230913/51ba16ba/attachment-0001.htm>