Bug 1025206 - openstack-nova: instance resize doesn't work
openstack-nova: instance resize doesn't work
Status: CLOSED NOTABUG
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova (Show other bugs)
3.0
x86_64 Linux
high Severity high
: async
: 3.0
Assigned To: Xavier Queralt
Ami Jeain
: ZStream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-31 05:02 EDT by Yogev Rabl
Modified: 2014-06-18 03:00 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-14 07:14:06 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
nova logs (4.35 KB, text/x-log)
2013-10-31 05:02 EDT, Yogev Rabl
no flags Details
scheduler.log during the action (21.21 KB, text/x-log)
2013-10-31 07:06 EDT, Yogev Rabl
no flags Details

  None (edit)
Description Yogev Rabl 2013-10-31 05:02:27 EDT
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 05:02:58 EDT
Created attachment 817765 [details]
nova logs
Comment 2 Xavier Queralt 2013-10-31 05:41:30 EDT
(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 07:06:59 EDT
Created attachment 817840 [details]
scheduler.log during the action

added the scheduler logs.
Comment 4 Xavier Queralt 2013-10-31 08:28:14 EDT
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 06:55:39 EST
(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 06:58:29 EST
(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 07:14:06 EST
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.

Note You need to log in before you can comment on or make changes to this bug.