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