Bug 1025206

Summary: openstack-nova: instance resize doesn't work
Product: Red Hat OpenStack Reporter: Yogev Rabl <yrabl>
Component: openstack-novaAssignee: Xavier Queralt <xqueralt>
Status: CLOSED NOTABUG QA Contact: Ami Jeain <ajeain>
Severity: high Docs Contact:
Priority: high    
Version: 3.0CC: dallan, hateya, ndipanov, xqueralt, yeylon, yrabl
Target Milestone: asyncKeywords: ZStream
Target Release: 3.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-14 12:14:06 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:
Attachments:
Description Flags
nova logs
none
scheduler.log during the action none

Description Yogev Rabl 2013-10-31 09:02:27 UTC
Description of problem:
The action of resize doesn't work on a newly created instance. The instance was created with the tiny flavor. The resize should've changed its flavor to small - but the action didn't affect the instance. 

The log (see attach) didn't raise any warning / error messages. 

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

openstack-nova-compute-2013.1.4-1.el6ost.noarch
openstack-dashboard-2013.1.4-1.el6ost.noarch
openstack-utils-2013.1-8.1.el6ost.noarch
openstack-glance-2013.1.4-1.el6ost.noarch
openstack-selinux-0.1.2-10.el6ost.noarch
openstack-cinder-2013.1.4-2.el6ost.noarch
openstack-nova-api-2013.1.4-1.el6ost.noarch
openstack-nova-console-2013.1.4-1.el6ost.noarch
openstack-nova-conductor-2013.1.4-1.el6ost.noarch
openstack-nova-novncproxy-0.4-6.el6ost.noarch
openstack-nova-network-2013.1.4-1.el6ost.noarch
openstack-nova-cert-2013.1.4-1.el6ost.noarch
python-django-openstack-auth-1.0.6-2.el6ost.noarch
redhat-access-plugin-openstack-1.2.0-6.el6ost.noarch
openstack-keystone-2013.1.4-1.el6ost.noarch
openstack-nova-common-2013.1.4-1.el6ost.noarch
openstack-nova-scheduler-2013.1.4-1.el6ost.noarch
openstack-packstack-2013.1.1-0.33.dev695.el6ost.noarch

OS version: 
Red Hat Enterprise Linux Server release 6.5 Beta

How reproducible:
everytime

Steps to Reproduce:
1. create a new instance 
2. try to change its flavor. 
3.

Actual results:
the instance flavor stays the same

Expected results:
the flavor should change to the new configuration

Additional info:

Comment 1 Yogev Rabl 2013-10-31 09:02:58 UTC
Created attachment 817765 [details]
nova logs

Comment 2 Xavier Queralt 2013-10-31 09:41:30 UTC
(In reply to Yogev Rabl from comment #1)
> Created attachment 817765 [details]
> nova logs

Could you attach the scheduler logs too? It is the component which takes care of finding a new host for the instance and there you will see the reason the instance has not been resized.

Comment 3 Yogev Rabl 2013-10-31 11:06:59 UTC
Created attachment 817840 [details]
scheduler.log during the action

added the scheduler logs.

Comment 4 Xavier Queralt 2013-10-31 12:28:14 UTC
I think you're trying to resize an instance with only one compute node and the 'allow_resize_to_same_host' configuration option unset (which defaults to False). This won't work as you can see because the scheduler will ignore the host where the instance is currently on and fail to find another host.

Could you try again and enable resizes in the same host (set allow_resize_to_same_host = true in nova.conf and restart the api and compute services) and/or add a second compute host?

Comment 5 Yogev Rabl 2013-11-14 11:55:39 UTC
(In reply to Xavier Queralt from comment #4)

you're correct, I should've changed the allow_resize_to_same_host parameter. why isn't set on true as default?

Comment 6 Yogev Rabl 2013-11-14 11:58:29 UTC
(In reply to Xavier Queralt from comment #4)

you were right, the allow_resize_to_same_host parameter was false, why isn't set on true as default?

Comment 7 Nikola Dipanov 2013-11-14 12:14:06 UTC
The option is False by default and there is no reason to deviate from that as it is a deployment/usage choice, and it is a sane default since resizing likely needs to involve the scheduler. Closing as not a bug.