The server was created in a specific zone with the POST /servers request containing the availability_zone parameter.
Le lun. 27 mars 2023 à 14:28, Sean Mooney <smooney@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@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@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>
>
> 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@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
> > > >
> >
> >