Open Stack

Yes. Thanks, but the things I would like to know: after instances are
created, how do we know if it was launched with specified AZ or without it?
I mean the way to distinguish between specified instances and non specified
instances?

Nguyen Huu Khoi


On Wed, Mar 29, 2023 at 5:05 PM Sylvain Bauza <sbauza at redhat.com> wrote:

>
>
> Le mer. 29 mars 2023 à 08:06, Nguyễn Hữu Khôi <nguyenhuukhoinw at gmail.com>
> a écrit :
>
>> 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.
>>
>>
> Correct, this is normal. If the operators creates some AZs, then the
> enduser should see where the instance in which AZ.
>
>
>> 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."
>>
>>
> To be clear, an operator can create Availability Zones. Those AZs can then
> be seen by an enduser using the os-availability-zones API [1]. Then, either
> the enduser wants to use a specific AZ for their next instance creation
> (and if so, he/she adds --availability-zone parameter to their instance
> creation client) or they don't want and then they don't provide this
> parameter.
>
> If they provide this parameter, then the server will be created only in
> one host in the specific AZ and then when moving the instance later, it
> will continue to move to any host within the same AZ.
> If they *don't* provide this parameter, then depending on the
> default_schedule_zone config option, either the instance will eventually
> use a specific AZ (and then it's like if the enduser was asking for this
> AZ), or none of AZ is requested and then the instance can be created and
> moved between any hosts within *all* AZs.
>
> That being said, as I said earlier, the enduser can still verify the AZ
> from where the instance is by the server show parameter you told.
>
> We also have a documentation explaining about Availability Zones, maybe
> this would help you more to understand about AZs :
> https://docs.openstack.org/nova/latest/admin/availability-zones.html
>
>
> [1]
> https://docs.openstack.org/api-ref/compute/#availability-zones-os-availability-zone
> (tbc, the enduser won't see the hosts, but they can see the list of
> existing AZs)
>
>
>
>> 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/0bce636d/attachment-0001.htm>