Ok, thank you all for your answers.
I see multiples options on the table here:
- have my controllers equally split across AZ and set a different
default_schedule_zone on each (sounds hacky to me)
- rework or add a new parameter that would behave like
default_schedule_zone but selecting randomly from a list instead of a
string
- add some sort of middleware so we can set the availability_zone param
if it's absent
There is another possibility to pin an instance : if the user attaches it to a volume and if cross_az_attach config option is set to False (default being True), then the instance is pinned to the volume AZ at the creation time.
I hear your thoughts on having a UX being "default to a random zone of from a list", this could be a blueprint and IMHO we wouldn't need to add a microversion as this is not a new API behaviour. That said, let's discuss this if you want at some meeting.
For your own cloud, well, indeed you only have to use different values for default_schedule_zone (that's a nova-api configuration option, so every API service could use a different value) for the moment.
-Sylvain
Cheers,
Arnaud
On 19.12.24 - 13:03, Damian Dabrowski wrote:
> Hi!
>
> yes, setting `default_schedule_zone` should help.
> But it doesn't really help when you don't want to have a default AZ and you
> just want to prevent a VM from being migrated between AZs.
>
> I've described the issue in this bug report some time ago:
> https://bugs.launchpad.net/nova/+bug/2047182
>
> Unfortunately, it turned out that it's quite hard to fix this behavior :/
>
> On Thu, Dec 19, 2024 at 12:56 PM Kees Meijs | Nefos <keesm@nefos.nl> wrote:
>
> > Hi,
> >
> > (Very) interested in this as well.
> >
> > So: +1
> >
> > Cheers,
> > Kees
> >
> > On 19-12-2024 12:36, Tobias Urdin - Binero IT wrote:
> >
> > IIRC this is the reason we are setting `default_schedule_zone` in nova.conf so
> > that the zone is populated explicitly in the request_spec in the database so that
> > it can’t be moved to another zone later, but im not 100% sure.
> >
> > Obviously the drawback being that you populate one zone only if none is
> > selected.
> >
> > I don’t think there is an option to “schedule to any zone and then hardcode it
> > in request_spec”, we would be interested if that’s available today or something
> > that could be added.
> >
> >
> >
> >