Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1421633

Summary: Any workaround of Bug #1444841 “Resize instance fails after creating host aggregate”
Product: Red Hat OpenStack Reporter: Masaki Furuta ( RH ) <mfuruta>
Component: openstack-novaAssignee: Radomir Dopieralski <rdopiera>
Status: CLOSED DUPLICATE QA Contact: Prasanth Anbalagan <panbalag>
Severity: medium Docs Contact:
Priority: medium    
Version: 10.0 (Newton)CC: berrange, dasmith, dclarke, eglynn, kchamart, rdopiera, sbauza, sferdjao, sgordon, srevivo, vromanso
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-02-22 08:30:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Masaki Furuta ( RH ) 2017-02-13 10:13:32 UTC
Description of problem:

  Any workaround of Bug #1444841 “Resize instance fails after creating host aggregate” : Bugs : OpenStack Compute (nova) ?

  (see Steps to Reproduce: and Additional info: below)



Version-Release number of selected component (if applicable):

  Reported against OSP8 , but looks also valid to OSP10 and newer.

How reproducible:
  100 %

Steps to Reproduce:
  
  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.

Actual results:

  https://bugs.launchpad.net/nova/+bug/1444841/comments/19
  ~~~
  The related ticket mentioned below is one example of a common mistake that is
  quite not easily fixable from the Nova standpoint since the design is mostly broken.

    Change-Id: I092c8caa9e450a68a7a952940b0bb288b8fe6fb0
    Related-Bug: #1444841
  ~~~

Expected results:

  Should be resized without error.


Additional info:

Upstream is about to start it clean up now.


- Bug #1444841 “Resize instance fails after creating host aggregate” : Bugs : OpenStack Compute (nova)
  https://bugs.launchpad.net/nova/+bug/1444841

~~~
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.
  
  Tags: kilo-backport-potential resize Edit Tag help


Qin Zhao (zhaoqin) wrote on 2015-04-16:	#1

  nova-scheduler reports 'no valid host', because AvailabilityZoneFilter gets AZ from instance property. If instance availability_zone column in db is inconsistent with host AZ, this filter will not select the host.

  When we add one host to a host aggregate, should we update instance AZ who running on this host? Or should we make instance AZ obsolete, and make AvailabilityZoneFilter to get AZ from host as 'nova list' does?

<....>

Matt Riedemann (mriedem) wrote on 2015-05-20:	#7

  Is this a duplicate of bug 1431194?

<....>

OpenStack Infra (hudson-openstack) wrote on 2015-09-15: Related fix proposed to nova (master)	#14

  Related fix proposed to branch: master
  Review: https://review.openstack.org/223802

<....>

OpenStack Infra (hudson-openstack) wrote on 2015-09-23: Related fix merged to nova (master)	#19

  Reviewed: https://review.openstack.org/223802
  Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=74abd14baf0f664a94d88272d43283ac7e6bbc1f
  Submitter: Jenkins
  Branch: master
  
  commit 74abd14baf0f664a94d88272d43283ac7e6bbc1f
  Author: Sylvain Bauza <email address hidden>
  Date: Tue Sep 15 22:33:24 2015 +0200
  
      Add some devref for AZs
  
      Since the AZ knowledge is mostly tribal and can have some corner cases, we could
      help the operators by giving more visibility on how it's made and what to prevent.
  
      The related ticket mentioned below is one example of a common mistake that is
      quite not easily fixable from the Nova standpoint since the design is mostly broken.
  
      Change-Id: I092c8caa9e450a68a7a952940b0bb288b8fe6fb0
      Related-Bug: #1444841
  
  Alan Pevec (apevec) on 2015-11-24
  tags:	removed: juno-backport-potential

<....>

Comment 1 Masaki Furuta ( RH ) 2017-02-15 07:46:09 UTC
Any news?

As per upstream commit below, I suppose there's no fix atm. 
But can we have any workaround rather than fix ?

~~~
OpenStack Infra (hudson-openstack) wrote on 2015-09-23: Related fix merged to nova (master)	#19

  Reviewed: https://review.openstack.org/223802
  Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=74abd14baf0f664a94d88272d43283ac7e6bbc1f
  Submitter: Jenkins
  Branch: master
  
  commit 74abd14baf0f664a94d88272d43283ac7e6bbc1f
  Author: Sylvain Bauza <email address hidden>
  Date: Tue Sep 15 22:33:24 2015 +0200
  
      Add some devref for AZs
  
      Since the AZ knowledge is mostly tribal and can have some corner cases, we could
      help the operators by giving more visibility on how it's made and what to prevent.
  
      The related ticket mentioned below is one example of a common mistake that is
      quite not easily fixable from the Nova standpoint since the design is mostly broken.
  
      Change-Id: I092c8caa9e450a68a7a952940b0bb288b8fe6fb0
      Related-Bug: #1444841
  
  Alan Pevec (apevec) on 2015-11-24
  tags:	removed: juno-backport-potential
~~~

Thought it's due to broken design, since this has impact customer's operation,  I'm really appreciate to hear your idea.

/Masaki

Comment 2 Diana Clarke 2017-02-21 19:54:08 UTC
Hi Masaki:

I was indeed able to reproduce the issue described in the following upstream bug, but only if I used the Horizon dashboard to create instances before creating my first real availability zone.

   Resize instance fails after creating host aggregate
   https://bugs.launchpad.net/nova/+bug/1444841

A quick summary:

    0. On a fresh install without instances or availability zones
    1. Create an instance via the Horizon dashboard (instance-1)
    2. Create an availability zone and host aggregate for the same host
    3. Attempt to resize instance-1 (and note the following error)

    ERROR (BadRequest): No valid host was found. No valid host found
for resize (HTTP 400)

The trouble appears to be that the Horizon dashboard doesn't allow you to not specify an availability zone when you create an instance, and if you haven't yet created any "real" availability zones, it will send the name of the default availability zone ("nova").

This is a documented, known, no-no: "it is highly recommended for users to never ever ask for booting an instance by specifying an explicit AZ named 'nova'"

    https://docs.openstack.org/developer/nova/aggregates.html#availability-zones-azs

If you use the command line interface to create instances and don't specify an availability zone, you will get a NULL in the database for 'availability_zone' (this is correct). If you use Horizon, you will get the string "nova" which will result in the resize issues you're seeing once you create other "real" availability zones.

Some workarounds:

1. Use the command line interface to create instances (nova boot) rather than the Horizon dashboard.

2. Or if you want to use the Horizon dashboard to create instances, make sure you create at least one real availability zone first.

Hope that helps!

Comment 4 Radomir Dopieralski 2017-02-22 08:30:00 UTC
I believe this has been recently addressed in https://bugzilla.redhat.com/show_bug.cgi?id=1417666 and the fix should become available soon.

*** This bug has been marked as a duplicate of bug 1417666 ***