[Yahoo-eng-team] [Bug 1615922] Re: pci device object doesn't set correctly during rolling upgrade
** Also affects: oslo.versionedobjects
Importance: Undecided
Status: New
** Changed in: oslo.versionedobjects
Assignee: (unassigned) => Hiroyuki Eguchi (h-eguchi)
** No longer affects: nova
--
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/1615922
Title:
pci device object doesn't set correctly during rolling upgrade
Status in oslo.versionedobjects:
New
Bug description:
I'm evaluating a rolling upgrade from liberty to mitaka in sr-iov
environment.
The following error occurred in resource_tracker in case controller
node is mitaka and compute node is liberty.
Error updating resources for node compute0: Cannot load 'parent_addr' in the
base classTraceback (most recent call last):
File "/usr/lib/python2.7/site-packages/nova/conductor/manager.py", line 85,
in _object_dispatch
return getattr(target, method)(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py", line
223, in wrapper
return fn(self, *args, **kwargs)
File "/usr/lib/python2.7/site-packages/nova/objects/pci_device.py", line
251, in save
updates = self.obj_get_changes()
File "/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py", line
604, in obj_get_changes
changes[key] = getattr(self, key)
File "/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py", line
67, in getter
self.obj_load_attr(name)
File "/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py", line
580, in obj_load_attr
_("Cannot load '%s' in the base class") % attrname)
NotImplementedError: Cannot load 'parent_addr' in the base class
The cause of error is that a parent_addr parameter which has been
added newly since mitaka is not set correctly.
We should consider the a pci device object that nova-conductor
receives from nova-compute does not have a parent_addr attribute.
To manage notifications about this bug go to:
https://bugs.launchpad.net/oslo.versionedobjects/+bug/1615922/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1615922] [NEW] pci device object doesn't set correctly during rolling upgrade
Public bug reported:
I'm evaluating a rolling upgrade from liberty to mitaka in sr-iov
environment.
The following error occurred in resource_tracker in case controller node
is mitaka and compute node is liberty.
Error updating resources for node overcloud-compute-0.localdomain: Cannot load
'parent_addr' in the base classTraceback (most recent call last):
File "/usr/lib/python2.7/site-packages/nova/conductor/manager.py", line 85,
in _object_dispatch
return getattr(target, method)(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py", line
223, in wrapper
return fn(self, *args, **kwargs)
File "/usr/lib/python2.7/site-packages/nova/objects/pci_device.py", line 251,
in save
updates = self.obj_get_changes()
File "/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py", line
604, in obj_get_changes
changes[key] = getattr(self, key)
File "/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py", line
67, in getter
self.obj_load_attr(name)
File "/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py", line
580, in obj_load_attr
_("Cannot load '%s' in the base class") % attrname)
NotImplementedError: Cannot load 'parent_addr' in the base class
The cause of error is that a parent_addr parameter which has been added newly
since mitaka is not set correctly.
We should consider the a pci device object that nova-conductor receives
from nova-compute does not have a parent_addr attribute.
** Affects: nova
Importance: Undecided
Assignee: Hiroyuki Eguchi (h-eguchi)
Status: New
** Changed in: nova
Assignee: (unassigned) => Hiroyuki Eguchi (h-eguchi)
--
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/1615922
Title:
pci device object doesn't set correctly during rolling upgrade
Status in OpenStack Compute (nova):
New
Bug description:
I'm evaluating a rolling upgrade from liberty to mitaka in sr-iov
environment.
The following error occurred in resource_tracker in case controller
node is mitaka and compute node is liberty.
Error updating resources for node overcloud-compute-0.localdomain: Cannot
load 'parent_addr' in the base classTraceback (most recent call last):
File "/usr/lib/python2.7/site-packages/nova/conductor/manager.py", line 85,
in _object_dispatch
return getattr(target, method)(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py", line
223, in wrapper
return fn(self, *args, **kwargs)
File "/usr/lib/python2.7/site-packages/nova/objects/pci_device.py", line
251, in save
updates = self.obj_get_changes()
File "/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py", line
604, in obj_get_changes
changes[key] = getattr(self, key)
File "/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py", line
67, in getter
self.obj_load_attr(name)
File "/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py", line
580, in obj_load_attr
_("Cannot load '%s' in the base class") % attrname)
NotImplementedError: Cannot load 'parent_addr' in the base class
The cause of error is that a parent_addr parameter which has been added newly
since mitaka is not set correctly.
We should consider the a pci device object that nova-conductor
receives from nova-compute does not have a parent_addr attribute.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1615922/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1598661] [NEW] Delete duplicate check when live-migrating
Public bug reported: A year ago I fixed a bug: https://review.openstack.org/#/c/195885/ The launchpad report: https://bugs.launchpad.net/nova/+bug/1469006 A above patch makes live-migration enable when instance is booted volume and has not local disk. A above patch performs the check via a call of _is_booted_from_volume and check the result if other checks (check_dest_data['is_shared_block_storage']) fails. However, this check has been already checked in _is_shared_block_storage method. The last part of the _is_shared_block_storage method does the same that above patch does: - check whether the instance is booted from volume. - check whether the instance has not a local disk. ** Affects: nova Importance: Undecided Assignee: Hiroyuki Eguchi (h-eguchi) Status: New ** Changed in: nova Assignee: (unassigned) => Hiroyuki Eguchi (h-eguchi) -- 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/1598661 Title: Delete duplicate check when live-migrating Status in OpenStack Compute (nova): New Bug description: A year ago I fixed a bug: https://review.openstack.org/#/c/195885/ The launchpad report: https://bugs.launchpad.net/nova/+bug/1469006 A above patch makes live-migration enable when instance is booted volume and has not local disk. A above patch performs the check via a call of _is_booted_from_volume and check the result if other checks (check_dest_data['is_shared_block_storage']) fails. However, this check has been already checked in _is_shared_block_storage method. The last part of the _is_shared_block_storage method does the same that above patch does: - check whether the instance is booted from volume. - check whether the instance has not a local disk. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1598661/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1587263] [NEW] A yesno filter should consider string
Public bug reported:
A yesno filter should consider string
For instance, a bootable item in cinder volume
can be string "true" or string "false".
So, a yesno filter returns "Yes" if value of bootable is string "false".
There is a possibility of same case in other item.
By all rights, we should change the type from string to boolean.
However, It would be better for us to consider a string data type in yesno
filter.
** Affects: horizon
Importance: Undecided
Assignee: Hiroyuki Eguchi (h-eguchi)
Status: In Progress
** Changed in: horizon
Assignee: (unassigned) => Hiroyuki Eguchi (h-eguchi)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1587263
Title:
A yesno filter should consider string
Status in OpenStack Dashboard (Horizon):
In Progress
Bug description:
A yesno filter should consider string
For instance, a bootable item in cinder volume
can be string "true" or string "false".
So, a yesno filter returns "Yes" if value of bootable is string
"false".
There is a possibility of same case in other item.
By all rights, we should change the type from string to boolean.
However, It would be better for us to consider a string data type in yesno
filter.
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1587263/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1562665] Re: Nova-compute connects to all of the iscsi target
** No longer affects: nova -- 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/1562665 Title: Nova-compute connects to all of the iscsi target Status in os-brick: In Progress Bug description: Nova-compute tries to connect to all of the iscsi target which discovered when using multhpath in Kilo. As a result , a lot of unnecessary iscsi sessions occur on the nova-compute. We have to choose correct targets from output of iscsiadm discovery by iscsi_properties of the volume we try to connect. Steps of attaching multipath device is like this: 1. discover iscsi targets 2. get all active iscsi sessions 3. compare 1. with 2. and connect to all iscsi targets not connected It should be like this: 1. discover iscsi targets 2. choose correct targets from output of discovery 3. get all active iscsi sessions 4. compare 2. with 3. and connect to the iscsi target if it is not connected To manage notifications about this bug go to: https://bugs.launchpad.net/os-brick/+bug/1562665/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1502804] Re: flavor id should be the same as the last one when updating
** Changed in: horizon Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1502804 Title: flavor id should be the same as the last one when updating Status in OpenStack Dashboard (Horizon): Invalid Bug description: When updating the flavor, horizon delete and recreate a flavor according to the specified value. At that time, horizon should specify the same value as the previous value to flavor id. Currently, horizon does not specify the flavor id, so a generated UUID value is specified. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1502804/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1565399] [NEW] A stale file handle error occurs when resizing
Public bug reported: This error can occur when resizing vm and resource tracker are executed at the same time. The cause of this bug is that the file path of a VM disk is changed temporarily when resizing. (from /var/lib/nova/instances/[UUID]/ to /var/lib/nova/instances/[UUID]_resize/) The _get_instance_disk_info method which gets a total disk size that all instance uses is executed periodically in resource_tracker. At that time, the os.path.getsize() method which gets a file size is executed. It is just a speculation, but the os.path.getsize() method consists of these steps. 1. open the file by using a fopen method in C 2. get the status of file by using a stat method in C At that time, if the file path of a VM disk is changed between 1. and 2., a errno.ESTALE will occur. So we have to take into account the OSError(errno.ESTALE) in order to avoid above error. It's a very rare case, however it can happen with a shared storage environment using slow NFS. ** Affects: nova Importance: Undecided Assignee: Hiroyuki Eguchi (h-eguchi) Status: New ** Changed in: nova Assignee: (unassigned) => Hiroyuki Eguchi (h-eguchi) -- 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/1565399 Title: A stale file handle error occurs when resizing Status in OpenStack Compute (nova): New Bug description: This error can occur when resizing vm and resource tracker are executed at the same time. The cause of this bug is that the file path of a VM disk is changed temporarily when resizing. (from /var/lib/nova/instances/[UUID]/ to /var/lib/nova/instances/[UUID]_resize/) The _get_instance_disk_info method which gets a total disk size that all instance uses is executed periodically in resource_tracker. At that time, the os.path.getsize() method which gets a file size is executed. It is just a speculation, but the os.path.getsize() method consists of these steps. 1. open the file by using a fopen method in C 2. get the status of file by using a stat method in C At that time, if the file path of a VM disk is changed between 1. and 2., a errno.ESTALE will occur. So we have to take into account the OSError(errno.ESTALE) in order to avoid above error. It's a very rare case, however it can happen with a shared storage environment using slow NFS. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1565399/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1562665] Re: Nova-compute connects to all of the iscsi target in Kilo
** Also affects: os-brick Importance: Undecided Status: New ** Changed in: os-brick Assignee: (unassigned) => Hiroyuki Eguchi (h-eguchi) -- 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/1562665 Title: Nova-compute connects to all of the iscsi target Status in OpenStack Compute (nova): Incomplete Status in os-brick: In Progress Bug description: Nova-compute tries to connect to all of the iscsi target which discovered when using multhpath in Kilo. As a result , a lot of unnecessary iscsi sessions occur on the nova-compute. We have to choose correct targets from output of iscsiadm discovery by iscsi_properties of the volume we try to connect. Steps of attaching multipath device is like this: 1. discover iscsi targets 2. get all active iscsi sessions 3. compare 1. with 2. and connect to all iscsi targets not connected It should be like this: 1. discover iscsi targets 2. choose correct targets from output of discovery 3. get all active iscsi sessions 4. compare 2. with 3. and connect to the iscsi target if it is not connected To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1562665/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1562665] [NEW] Nova-compute connects to all of the iscsi target in Kilo
Public bug reported: Nova-compute tries to connect to all of the iscsi target which discovered when using multhpath in Kilo. As a result , a lot of unnecessary iscsi sessions occur on the nova-compute. We have to choose correct targets from output of iscsiadm discovery by iscsi_properties of the volume we try to connect. Steps of attaching multipath device is like this: 1. discover iscsi targets 2. get all active iscsi sessions 3. compare 1. with 2. and connect to all iscsi targets not connected It should be like this: 1. discover iscsi targets 2. choose correct targets from output of discovery 3. get all active iscsi sessions 4. compare 2. with 3. and connect to the iscsi target if it is not connected ** Affects: nova Importance: Undecided Assignee: Hiroyuki Eguchi (h-eguchi) Status: New ** Changed in: nova Assignee: (unassigned) => Hiroyuki Eguchi (h-eguchi) -- 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/1562665 Title: Nova-compute connects to all of the iscsi target in Kilo Status in OpenStack Compute (nova): New Bug description: Nova-compute tries to connect to all of the iscsi target which discovered when using multhpath in Kilo. As a result , a lot of unnecessary iscsi sessions occur on the nova-compute. We have to choose correct targets from output of iscsiadm discovery by iscsi_properties of the volume we try to connect. Steps of attaching multipath device is like this: 1. discover iscsi targets 2. get all active iscsi sessions 3. compare 1. with 2. and connect to all iscsi targets not connected It should be like this: 1. discover iscsi targets 2. choose correct targets from output of discovery 3. get all active iscsi sessions 4. compare 2. with 3. and connect to the iscsi target if it is not connected To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1562665/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1502804] [NEW] flavor id should be the same as the last one when updating
Public bug reported: When updating the flavor, horizon delete and recreate a flavor according to the specified value. At that time, horizon should specify the same value as the previous value to flavor id. Currently, horizon does not specify the flavor id, so a generated UUID value is specified. ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1502804 Title: flavor id should be the same as the last one when updating Status in OpenStack Dashboard (Horizon): New Bug description: When updating the flavor, horizon delete and recreate a flavor according to the specified value. At that time, horizon should specify the same value as the previous value to flavor id. Currently, horizon does not specify the flavor id, so a generated UUID value is specified. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1502804/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1500337] [NEW] Rollback of live-migration fails in the case of cinder with the NFS driver
Public bug reported:
This error occurs under the following situations.
- cinder is using the NFS driver.
- cinder volume is attached to the instance.
- fail to live migrate before destination host attach to the NFS server
We should consider whether destination host has mounted to NFS server or
not when executing rollback of live-migration .
ProcessExecutionError: Unexpected error while running command.
Command: sudo nova-rootwrap /etc/nova/rootwrap.conf umount
/var/lib/nova/mnt/b5e2fcf5ad9470489747f7caa242747b
Exit code: 32
Stdout: u''
Stderr: u'umount: /var/lib/nova/mnt/b5e2fcf5ad9470489747f7caa242747b: not
mounted\n'
** Affects: nova
Importance: Undecided
Assignee: Hiroyuki Eguchi (h-eguchi)
Status: New
** Changed in: nova
Assignee: (unassigned) => Hiroyuki Eguchi (h-eguchi)
--
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/1500337
Title:
Rollback of live-migration fails in the case of cinder with the NFS
driver
Status in OpenStack Compute (nova):
New
Bug description:
This error occurs under the following situations.
- cinder is using the NFS driver.
- cinder volume is attached to the instance.
- fail to live migrate before destination host attach to the NFS server
We should consider whether destination host has mounted to NFS server
or not when executing rollback of live-migration .
ProcessExecutionError: Unexpected error while running command.
Command: sudo nova-rootwrap /etc/nova/rootwrap.conf umount
/var/lib/nova/mnt/b5e2fcf5ad9470489747f7caa242747b
Exit code: 32
Stdout: u''
Stderr: u'umount: /var/lib/nova/mnt/b5e2fcf5ad9470489747f7caa242747b: not
mounted\n'
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1500337/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1497125] [NEW] fail to live-migrate a booted from volume vm which have a local disk.
Public bug reported: fail to live-migrate a booted from volume vm which have a local disk. message: "hostA is not on shared storage: Live migration can not be used without shared storage except a booted from volume VM which does not have a local disk." make it enable by copying local files (swap, ephemeral disk, config- drive) from the source host to the destination host in pre_live_migration. ** Affects: nova Importance: Undecided Assignee: Hiroyuki Eguchi (h-eguchi) Status: New ** Description changed: fail to live-migrate a booted from volume vm which have a local disk. - - message: "hostA is not on shared storage: Live migration can not be used - without shared storage except a booted from volume VM which does not - have a local disk." + message: "hostA is not on shared storage: Live migration can not be used without shared storage except a booted from volume VM which does not have a local disk." make it enable by copying local files (swap, ephemeral disk, config- drive) from the source host to the destination host in pre_live_migration. ** Changed in: nova Assignee: (unassigned) => Hiroyuki Eguchi (h-eguchi) -- 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/1497125 Title: fail to live-migrate a booted from volume vm which have a local disk. Status in OpenStack Compute (nova): New Bug description: fail to live-migrate a booted from volume vm which have a local disk. message: "hostA is not on shared storage: Live migration can not be used without shared storage except a booted from volume VM which does not have a local disk." make it enable by copying local files (swap, ephemeral disk, config- drive) from the source host to the destination host in pre_live_migration. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1497125/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1474253] [NEW] Cannot rebuild a instance booted from volume
Public bug reported: User rebuild a instance booted from volume in the following steps. 1. Stop a instance 2. Detach a root device volume. 3. Attach a new root device volume. 4. Start a instance But, currently, It's impossible by these reasons. 1. User not allowed to detach a root device volume. - detach boot device volume without warning (https://bugs.launchpad.net/nova/+bug/1279300) 2. User not allowed to attach a root device volume expect when creating a instance. - A get_next_device_name which is executed when attaching volume, never return a root_device_name. ** Affects: nova Importance: Undecided Status: New -- 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/1474253 Title: Cannot rebuild a instance booted from volume Status in OpenStack Compute (nova): New Bug description: User rebuild a instance booted from volume in the following steps. 1. Stop a instance 2. Detach a root device volume. 3. Attach a new root device volume. 4. Start a instance But, currently, It's impossible by these reasons. 1. User not allowed to detach a root device volume. - detach boot device volume without warning (https://bugs.launchpad.net/nova/+bug/1279300) 2. User not allowed to attach a root device volume expect when creating a instance. - A get_next_device_name which is executed when attaching volume, never return a root_device_name. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1474253/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1469006] [NEW] Live migration fails with a booted from volume instance
Public bug reported: This error always occurr in case of a non shared storage environment even if the instance is booted from volume. # nova live-migration c5993bdb-c230-48b4-ba42-70c680372640 dest_host ERROR (BadRequest): src_host is not on shared storage: Live migration can not be used without shared storage. (HTTP 400) (Request-ID: req- 22dc7adb-fd13-40fd-b7da-10c2851df528) We should allow user to execute live migration in case of a booted from volume instance. ** Affects: nova Importance: Undecided Assignee: Hiroyuki Eguchi (h-eguchi) Status: New ** Changed in: nova Assignee: (unassigned) => Hiroyuki Eguchi (h-eguchi) -- 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/1469006 Title: Live migration fails with a booted from volume instance Status in OpenStack Compute (Nova): New Bug description: This error always occurr in case of a non shared storage environment even if the instance is booted from volume. # nova live-migration c5993bdb-c230-48b4-ba42-70c680372640 dest_host ERROR (BadRequest): src_host is not on shared storage: Live migration can not be used without shared storage. (HTTP 400) (Request-ID: req- 22dc7adb-fd13-40fd-b7da-10c2851df528) We should allow user to execute live migration in case of a booted from volume instance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1469006/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1399098] [NEW] qemu-img convert should be skipped when migrating.
Public bug reported: Currently, qemu image is always converted when resizing and migrating. I guess this process is to prevent a original disk image corrupting when expanding the disk size. So qemu-img convert should be skipped when migrating and resizing (when the disk image of new flavor is same the old one). The qemu-img convert is IO heavy process, so I'd like to skip, if possible. ** Affects: nova Importance: Undecided Status: New -- 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/1399098 Title: qemu-img convert should be skipped when migrating. Status in OpenStack Compute (Nova): New Bug description: Currently, qemu image is always converted when resizing and migrating. I guess this process is to prevent a original disk image corrupting when expanding the disk size. So qemu-img convert should be skipped when migrating and resizing (when the disk image of new flavor is same the old one). The qemu-img convert is IO heavy process, so I'd like to skip, if possible. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1399098/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1327723] Re: The frequency of update_etc_hosts and update_hostname
sorry. It's wrong report. ** Changed in: cloud-init Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1327723 Title: The frequency of update_etc_hosts and update_hostname Status in Init scripts for use on cloud images: Invalid Bug description: The frequency of update_etc_hosts and update_hostname should be PER_INSTANCE. Some IaaS services allow user to update the name of instance. when updating name of instance, user have to edit /etc/hosts and /etc/hostname manually. But Now, these files are updated by cloud-init when rebooting, because the frequency of update_etc_hosts and update_hostname is PER_ALWAYS. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1327723/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1327723] [NEW] The frequency of update_etc_hosts and update_hostname
Public bug reported: The frequency of update_etc_hosts and update_hostname should be PER_INSTANCE. Some IaaS services allow user to update the name of instance. when updating name of instance, user have to edit /etc/hosts and /etc/hostname manually. But Now, these files are updated by cloud-init when rebooting, because the frequency of update_etc_hosts and update_hostname is PER_ALWAYS. ** Affects: cloud-init Importance: Undecided Status: New ** Branch linked: lp:~h-eguchi/cloud-init/update-hostname-per-instance -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1327723 Title: The frequency of update_etc_hosts and update_hostname Status in Init scripts for use on cloud images: New Bug description: The frequency of update_etc_hosts and update_hostname should be PER_INSTANCE. Some IaaS services allow user to update the name of instance. when updating name of instance, user have to edit /etc/hosts and /etc/hostname manually. But Now, these files are updated by cloud-init when rebooting, because the frequency of update_etc_hosts and update_hostname is PER_ALWAYS. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1327723/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1296532] Re: Network interface should be restarted if instance has a static ip address.
** Changed in: cloud-init
Status: New => Incomplete
** Changed in: cloud-init
Status: Incomplete => New
** Changed in: cloud-init
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1296532
Title:
Network interface should be restarted if instance has a static ip
address.
Status in Init scripts for use on cloud images:
Invalid
Bug description:
Network interface should be restarted if instance has a static ip
address.
Details are as follows.
1. create a instance with specifying a static ip address A.
2. create a snapshot of a instance.
3. create a instance from snapshot with specifying a static ip address
B.
3.1 instance start (At this time, network interface is still specified to
use ip address A.)
3.2 cloud-init edits /etc/network/interface to use ip address B.
3.3 cloud-init executes ifup command.
but network interface has already up, so new network information is not
reflected.
We have to modify the _bring_up_interface method like this.
--- cloudinit/distros/__init__.py 2014-02-12 19:56:55 +
+++ cloudinit/distros/__init__.py 2014-03-24 05:59:00 +
@@ -271,11 +271,13 @@
util.write_file(self.hosts_fn, contents.getvalue(), mode=0644)
def _bring_up_interface(self, device_name):
-cmd = ['ifup', device_name]
-LOG.debug("Attempting to run bring up interface %s using command %s",
- device_name, cmd)
+cmd_down = ['ifdown', device_name]
+cmd_up = ['ifup', device_name]
+LOG.debug("Attempting to restart interface %s using command %s %s",
+ device_name, cmd_down, cmd_up)
try:
-(_out, err) = util.subp(cmd)
+(_out, down_err) = util.subp(cmd_down)
+(_out, up_err) = util.subp(cmd_up)
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1296532/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1296532] [NEW] Network interface should be restarted if instance has a static ip address.
Public bug reported:
Network interface should be restarted if instance has a static ip
address.
Details are as follows.
1. create a instance with specifying a static ip address A.
2. create a snapshot of a instance.
3. create a instance from snapshot with specifying a static ip address
B.
3.1 instance start (At this time, network interface is still specified to use
ip address A.)
3.2 cloud-init edits /etc/network/interface to use ip address B.
3.3 cloud-init executes ifup command.
but network interface has already up, so new network information is not
reflected.
We have to modify the _bring_up_interface method like this.
--- cloudinit/distros/__init__.py 2014-02-12 19:56:55 +
+++ cloudinit/distros/__init__.py 2014-03-24 05:59:00 +
@@ -271,11 +271,13 @@
util.write_file(self.hosts_fn, contents.getvalue(), mode=0644)
def _bring_up_interface(self, device_name):
-cmd = ['ifup', device_name]
-LOG.debug("Attempting to run bring up interface %s using command %s",
- device_name, cmd)
+cmd_down = ['ifdown', device_name]
+cmd_up = ['ifup', device_name]
+LOG.debug("Attempting to restart interface %s using command %s %s",
+ device_name, cmd_down, cmd_up)
try:
-(_out, err) = util.subp(cmd)
+(_out, down_err) = util.subp(cmd_down)
+(_out, up_err) = util.subp(cmd_up)
** Affects: cloud-init
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1296532
Title:
Network interface should be restarted if instance has a static ip
address.
Status in Init scripts for use on cloud images:
New
Bug description:
Network interface should be restarted if instance has a static ip
address.
Details are as follows.
1. create a instance with specifying a static ip address A.
2. create a snapshot of a instance.
3. create a instance from snapshot with specifying a static ip address
B.
3.1 instance start (At this time, network interface is still specified to
use ip address A.)
3.2 cloud-init edits /etc/network/interface to use ip address B.
3.3 cloud-init executes ifup command.
but network interface has already up, so new network information is not
reflected.
We have to modify the _bring_up_interface method like this.
--- cloudinit/distros/__init__.py 2014-02-12 19:56:55 +
+++ cloudinit/distros/__init__.py 2014-03-24 05:59:00 +
@@ -271,11 +271,13 @@
util.write_file(self.hosts_fn, contents.getvalue(), mode=0644)
def _bring_up_interface(self, device_name):
-cmd = ['ifup', device_name]
-LOG.debug("Attempting to run bring up interface %s using command %s",
- device_name, cmd)
+cmd_down = ['ifdown', device_name]
+cmd_up = ['ifup', device_name]
+LOG.debug("Attempting to restart interface %s using command %s %s",
+ device_name, cmd_down, cmd_up)
try:
-(_out, err) = util.subp(cmd)
+(_out, down_err) = util.subp(cmd_down)
+(_out, up_err) = util.subp(cmd_up)
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1296532/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
