Open Stack

Hello.
I have one question.
Follow this

https://docs.openstack.org/nova/latest/admin/availability-zones.html

If the server was not created in a specific zone then it is free to be
moved to other zones. but when I use

openstack server show [server id]

I still see the "OS-EXT-AZ:availability_zone" value belonging to my
instance.

Could you tell the difference which causes "if the server was not created
in a specific zone then it is free to be moved to other zones."

Nguyen Huu Khoi


On Mon, Mar 27, 2023 at 8:37 PM Nguyễn Hữu Khôi <nguyenhuukhoinw at gmail.com>
wrote:

> Hello guys.
>
> I just suggest to openstack nova works better. My story because
>
>
>    1.
>
>    The server was created in a specific zone with the POST /servers request
>    containing the availability_zone parameter.
>
> It will be nice when we attach randow zone when we create instances then
> It will only move to the same zone when migrating or masakari ha.
>
> Currently we can force it to zone by default zone shedule in nova.conf.
>
> Sorry because I am new to Openstack and I am just an operator. I try to
> verify some real cases.
>
>
>
> Nguyen Huu Khoi
>
>
> On Mon, Mar 27, 2023 at 7:43 PM Sylvain Bauza <sbauza at redhat.com> wrote:
>
>>
>>
>> Le lun. 27 mars 2023 à 14:28, Sean Mooney <smooney at redhat.com> a écrit :
>>
>>> On Mon, 2023-03-27 at 14:06 +0200, Sylvain Bauza wrote:
>>> > Le lun. 27 mars 2023 à 13:51, Sean Mooney <smooney at redhat.com> a
>>> écrit :
>>> >
>>> > > On Mon, 2023-03-27 at 10:19 +0200, Sylvain Bauza wrote:
>>> > > > Le dim. 26 mars 2023 à 14:30, Rafael Weingärtner <
>>> > > > rafaelweingartner at gmail.com> a écrit :
>>> > > >
>>> > > > > Hello Nguyễn Hũu Khôi,
>>> > > > > You might want to take a look at:
>>> > > > > https://review.opendev.org/c/openstack/nova/+/864760. We
>>> created a
>>> > > patch
>>> > > > > to avoid migrating VMs to any AZ, once the VM has been
>>> bootstrapped in
>>> > > an
>>> > > > > AZ that has cross zone attache equals to false.
>>> > > > >
>>> > > > >
>>> > > > Well, I'll provide some comments in the change, but I'm afraid we
>>> can't
>>> > > > just modify the request spec like you would want.
>>> > > >
>>> > > > Anyway, if you want to discuss about it in the vPTG, just add it
>>> in the
>>> > > > etherpad and add your IRC nick so we could try to find a time
>>> where we
>>> > > > could be discussing it :
>>> https://etherpad.opendev.org/p/nova-bobcat-ptg
>>> > > > Also, this kind of behaviour modification is more a new feature
>>> than a
>>> > > > bugfix, so fwiw you should create a launchpad blueprint so we could
>>> > > better
>>> > > > see it.
>>> > >
>>> > > i tought i left review feedback on that too that the approch was not
>>> > > correct.
>>> > > i guess i did not in the end.
>>> > >
>>> > > modifying the request spec as sylvain menthioned is not correct.
>>> > > i disucssed this topic on irc a few weeks back with mohomad for
>>> vxhost.
>>> > > what can be done is as follows.
>>> > >
>>> > > we can add a current_az field  to the Destination object
>>> > >
>>> > >
>>> https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L1092-L1122
>>> > > The conductor can read the instance.AZ and populate it in that new
>>> field.
>>> > > We can then add a new weigher to prefer hosts that are in the same
>>> az.
>>> > >
>>> > >
>>> >
>>> > I tend to disagree this approach as people would think that the
>>> > Destination.az field would be related to the current AZ for an
>>> instance,
>>> > while we only look at the original AZ.
>>> > That being said, we could have a weigher that would look at whether the
>>> > host is in the same AZ than the instance.host.
>>> you miss understood what i wrote
>>>
>>> i suggested addint Destination.current_az to store teh curernt AZ of the
>>> instance before scheduling.
>>>
>>> so my proposal is if RequestSpec.AZ is not set and
>>> Destination.current_az is set then the new
>>> weigher would prefer hosts that are in the same az as
>>> Destination.current_az
>>>
>>> we coudl also call Destination.current_az Destination.prefered_az
>>>
>>>
>> I meant, I think we don't need to provide a new field, we can already
>> know about what host an existing instance uses if we want (using [1])
>> Anyway, let's stop to discuss about it here, we should rather review that
>> for a Launchpad blueprint or more a spec.
>>
>> -Sylvain
>>
>> [1]
>> https://github.com/openstack/nova/blob/b9a49ffb04cb5ae2d8c439361a3552296df02988/nova/scheduler/host_manager.py#L369-L370
>>
>>> >
>>> >
>>> > This will provide soft AZ affinity for the vm and preserve the fact
>>> that if
>>> > > a vm is created without sepcifying
>>> > > An AZ the expectaiton at the api level woudl be that it can migrate
>>> to any
>>> > > AZ.
>>> > >
>>> > > To provide hard AZ affintiy we could also add prefileter that would
>>> use
>>> > > the same data but instead include it in the
>>> > > placement query so that only the current AZ is considered. This
>>> would have
>>> > > to be disabled by default.
>>> > >
>>> > >
>>> > Sure, we could create a new prefilter so we could then deprecate the
>>> > AZFilter if we want.
>>> we already have an AZ prefilter and the AZFilter is deprecate for removal
>>> i ment to delete it in zed but did not have time to do it in zed of
>>> Antielope
>>> i deprecated the AZ| filter in
>>> https://github.com/openstack/nova/commit/7c7a2a142d74a7deeda2a79baf21b689fe32cd08
>>> xena when i enabeld the az prefilter by default.
>>>
>>>
>> Ah whoops, indeed I forgot the fact we already have the prefilter, so the
>> hard support for AZ is already existing.
>>
>>
>>> i will try an delete teh AZ filter before m1 if others dont.
>>>
>>
>> OK.
>>
>>
>>> >
>>> >
>>> > > That woudl allow operators to choose the desired behavior.
>>> > > curret behavior (disable weigher and dont enabel prefilter)
>>> > > new default, prefer current AZ (weigher enabeld prefilter disabled)
>>> > > hard affintiy(prefilter enabled.)
>>> > >
>>> > > there are other ways to approch this but updating the request spec
>>> is not
>>> > > one of them.
>>> > > we have to maintain the fact the enduser did not request an AZ.
>>> > >
>>> > >
>>> > Anyway, if folks want to discuss about AZs, this week is the good time
>>> :-)
>>> >
>>> >
>>> > > >
>>> > > > -Sylvain
>>> > > >
>>> > > >
>>> > > >
>>> > > > > On Sun, Mar 26, 2023 at 8:20 AM Nguyễn Hữu Khôi <
>>> > > nguyenhuukhoinw at gmail.com>
>>> > > > > wrote:
>>> > > > >
>>> > > > > > Hello guys.
>>> > > > > > I playing with Nova AZ and Masakari
>>> > > > > >
>>> > > > > >
>>> https://docs.openstack.org/nova/latest/admin/availability-zones.html
>>> > > > > >
>>> > > > > > Masakari will move server by nova scheduler.
>>> > > > > >
>>> > > > > > Openstack Docs describe that:
>>> > > > > >
>>> > > > > > If the server was not created in a specific zone then it is
>>> free to
>>> > > be
>>> > > > > > moved to other zones, i.e. the AvailabilityZoneFilter
>>> > > > > > <
>>> > >
>>> https://docs.openstack.org/nova/latest/admin/scheduling.html#availabilityzonefilter
>>> >
>>> > > is
>>> > > > > > a no-op.
>>> > > > > >
>>> > > > > > I see that everyone usually creates instances with "Any
>>> Availability
>>> > > > > > Zone" on Horzion and also we don't specify AZ when creating
>>> > > instances by
>>> > > > > > cli.
>>> > > > > >
>>> > > > > > By this way, when we use Masakari or we miragrated instances(
>>> or
>>> > > > > > evacuate) so our instance will be moved to other zones.
>>> > > > > >
>>> > > > > > Can we attach AZ to server create requests API based on Any
>>> > > > > > Availability Zone to limit instances moved to other zones?
>>> > > > > >
>>> > > > > > Thank you. Regards
>>> > > > > >
>>> > > > > > Nguyen Huu Khoi
>>> > > > > >
>>> > > > >
>>> > > > >
>>> > > > > --
>>> > > > > Rafael Weingärtner
>>> > > > >
>>> > >
>>> > >
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230329/9e78c3e0/attachment-0001.htm>