Open Stack

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/20230327/409b0a92/attachment-0001.htm>