yahoo-eng-team team mailing list archive

[Sylvain Bauza <sbauza@xxxxxxx>]

Okay, so I feel the bug should be marked as Invalid. Why ? Let me
explain :

While any instance can be shown with an AZ, it doesn't mean that the instance.az field is set with that value but rather showing the value of CONF.default_availability_zone if that field is left blank.
How to the instance.az field is set ? That's populated once in the instance lifetime at the Compute API level here:
https://github.com/openstack/nova/blob/79fe4d8e076c9c7bb76f0afb1b2787d51b2c5037/nova/compute/api.py#L1147-L1161

As you can see, it calls _handle_availability_zone which reads what the API received and defaults to CONF.default_schedule_zone :
https://github.com/openstack/nova/blob/79fe4d8e076c9c7bb76f0afb1b2787d51b2c5037/nova/compute/api.py#L596-L597

As CONF.default_schedule_zone is defaulted to None (
https://github.com/openstack/nova/blob/79fe4d8e076c9c7bb76f0afb1b2787d51b2c5037/nova/compute/api.py#L92-L93
) that means that a default nova boot command (without using the
--availability_zone flag) will create an Instance entry in the table
with an AZ field equals to NULL.

When it comes to the AZ filter, if the instance.az field is set to None,
then the filter always returns True (which makes sense because the user
didn't specify an AZ to stick with).


So, now that I explained how it works, lemme explain the error here : by specifying an AZ in the boot command, it will do the exact opposite : it will stick the instance to be created to the AZ provided. Since the bug reporter provided a value (even for the default value of "nova"), it means that then the instance.az field became "nova".

For the original boot, the AZ filter checked if the host was having an
aggregate. Since it was not the case, it checked if the instance AZ
(here "nova') was equal to CONF.default_availability_zone (defaulted to
"nova')
https://github.com/openstack/nova/blob/3aff2d7bff7f6e9edb5fa8b688287265722c27fb/nova/scheduler/filters/availability_zone_filter.py#L54
Yay, it worked.

Now, what happened once the host was part of the aggregate ? It didn't
change the instance.AZ field since that field doesn't change for the
whole lifetime of the instance (kept as an information of what the user
requested) but it ends to the AZ Filter which then sees that the host
belongs now to an aggregate and consequently matches the host.AZ with
the instance.az which was False this time
https://github.com/openstack/nova/blob/3aff2d7bff7f6e9edb5fa8b688287265722c27fb/nova/scheduler/filters/availability_zone_filter.py#L51

To be honest, rule of thumb : Never ever calls explicitely an AZ "nova",
either when booting an instance or when putting an AZ to an aggregate,
that will just prevent the default behaviour to work unless you modify
CONF.default_schedule_zone


** Changed in: nova
       Status: In Progress => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1444841

Title:
  Resize instance fails after creating host aggregate

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  Latest Kilo code

  
  Reproduce steps:

  1. Do not define any host aggregate. AZ of host is 'nova'. Boot one
  instance named 'zhaoqin-nova' whose AZ is 'nova'

  2. Create host aggregate 'zhaoqin' whose AZ is 'zhaoqin-az'. Add host
  to 'zhaoqin' aggregate.  Now AZ of instance 'zhaoqin-nova' in db is
  still 'nova'; and 'nova list' displays AZ of 'zhaoqin-nova' is
  'zhaoqin-az'.

  3. Resize 'zhaoqin-nova' fails, no valid host.

  4. Boot another instance 'zhaoqin-my-az' whose AZ is 'zhaoqin-az'.
  Resize 'zhaoqin-my-az' succeed.

  5. Remove host from aggregate 'zhaoqin'.

  6. Resize 'zhaoqin-nova' succeed.  Resize 'zhaoqin-my-az' fails, no
  valid host.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1444841/+subscriptions