Open Stack

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.


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.


> 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/20230327/75c8be84/attachment.htm>