Bug 1025206 - openstack-nova: instance resize doesn't work
Summary: openstack-nova: instance resize doesn't work
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova
Version: 3.0
Hardware: x86_64
OS: Linux
high
high
Target Milestone: async
: 3.0
Assignee: Xavier Queralt
QA Contact: Ami Jeain
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-31 09:02 UTC by Yogev Rabl
Modified: 2019-09-09 13:33 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-14 12:14:06 UTC
Target Upstream Version:
Embargoed:


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

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.


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