[Yahoo-eng-team] [Bug 1631481] [NEW] Revert resize does not delete instance directory with Ceph

[Feodor Tersin]

Public bug reported:

Resize revertion leaves instance directory on the second host with Ceph
image backend. As the result the second attempt to resize the instance
to the same host fails with n-cpu.log:

Traceback (most recent call last):
  File "/opt/stack/nova/nova/compute/manager.py", line 3942, in finish_resize
disk_info, image_meta)
  File "/opt/stack/nova/nova/compute/manager.py", line 3907, in _finish_resize
old_instance_type)
  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in 
__exit__
self.force_reraise()
  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
six.reraise(self.type_, self.value, self.tb)
  File "/opt/stack/nova/nova/compute/manager.py", line 3902, in _finish_resize
block_device_info, power_on)
  File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 7185, in 
finish_migration
self._ensure_console_log_for_instance(instance)
  File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 2845, in 
_ensure_console_log_for_instance
libvirt_utils.file_open(console_file, 'a').close()
  File "/opt/stack/nova/nova/virt/libvirt/utils.py", line 313, in file_open
return open(*args, **kwargs)
IOError: [Errno 13] Permission denied: 
'/opt/stack/data/nova/instances/ad52ca5b-bb65-4f7c-87e8-750cb3cd9c5e/console.log'

$ ll ~/data/nova/instances/ad52ca5b-bb65-4f7c-87e8-750cb3cd9c5e/
total 24
-rw-rw-r--. 1 qemu  qemu 19342 Oct  7 21:23 console.log
-rw-rw-r--. 1 stack libvirtd  2762 Oct  7 21:22 libvirt.xml

Steps to reproduce:
1 Run 2-nodes devstack with Ceph image backend
2 Run an instance
 $ nova boot --image cirros-0.3.4-x86_64-disk --flavor t1.nano inst-1
3 Disable the instance host
 $ nova service-disable 172.16.1.10 nova-compute
4 Resize the instance to another host
 $ nova migrate inst-1
5 Revert resize
 $ nova resize-revert inst-1
6 Resize the instance again
 $ nova migrate inst-1
7 Check the instance state

Actual result - the instance is in error state.
Expected result - the instance is in verify_resize state.

Check n-cpu.log on the second node, where the instance was migrated.

This has been reproduced on master
commit 9c89e07d17b5eb441682e3b8fad8b270f37f7015
Merge: 870a77f 453e71d
Author: Jenkins 
Date:   Wed Oct 5 01:35:48 2016 +

** Affects: nova
 Importance: Undecided
 Status: New

** Description changed:

  Resize revertion leaves instance directory on the second host with Ceph
  image backend. As the result the second attempt to resize the instance
  to the same host fails with n-cpu.log:
  
  Traceback (most recent call last):
-   File "/opt/stack/nova/nova/compute/manager.py", line 3942, in finish_resize
- disk_info, image_meta)
-   File "/opt/stack/nova/nova/compute/manager.py", line 3907, in _finish_resize
- old_instance_type)
-   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, 
in __exit__
- self.force_reraise()
-   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, 
in force_reraise
- six.reraise(self.type_, self.value, self.tb)
-   File "/opt/stack/nova/nova/compute/manager.py", line 3902, in _finish_resize
- block_device_info, power_on)
-   File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 7185, in 
finish_migration
- self._ensure_console_log_for_instance(instance)
-   File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 2845, in 
_ensure_console_log_for_instance
- libvirt_utils.file_open(console_file, 'a').close()
-   File "/opt/stack/nova/nova/virt/libvirt/utils.py", line 313, in file_open
- return open(*args, **kwargs)
+   File "/opt/stack/nova/nova/compute/manager.py", line 3942, in finish_resize
+ disk_info, image_meta)
+   File "/opt/stack/nova/nova/compute/manager.py", line 3907, in _finish_resize
+ old_instance_type)
+   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, 
in __exit__
+ self.force_reraise()
+   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, 
in force_reraise
+ six.reraise(self.type_, self.value, self.tb)
+   File "/opt/stack/nova/nova/compute/manager.py", line 3902, in _finish_resize
+ block_device_info, power_on)
+   File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 7185, in 
finish_migration
+ self._ensure_console_log_for_instance(instance)
+   File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 2845, in 
_ensure_console_log_for_instance
+ libvirt_utils.file_open(console_file, 'a').close()
+   File "/opt/stack/nova/nova/virt/libvirt/utils.py", line 313, in file_open
+ return open(*args, **kwargs)
  IOError: [Errno 13] Permission denied: 
'/opt/stack/data/nova/instances/ad52ca5b-bb65-4f7c-87e8-750cb3cd9c5e/console.log'
  
  $ ll ~/data/nova/instances/ad52ca5b-bb65-4f7c-87e8-750cb3cd9c5e/
  total 24
  -rw-rw-r--. 1 qemu  qemu 19342 Oct  7 21:23 console.log
  -rw-rw-r--. 1 stack libvirtd  2762 Oct  7 21:22 libvirt.xml
  

[Yahoo-eng-team] [Bug 1596957] [NEW] Cannot resize down instance booted from volume backed snapshot with ephemeral

[Feodor Tersin]

Public bug reported:

If an instance is booted from a volume backed snapshot with
ephemeral(s), it cannot be resized down to a flawor with disk size is
lesser than original flavor disk size.

Steps to reproduce:

1 Prepare flavors
$ nova flavor-create t1.nano-2-e auto 64 2 1 --ephemeral 1
$ nova flavor-create t1.nano-1-e auto 64 1 1 --ephemeral 1

2 Prepare a volume backed snapshot
$ cinder create 2 --image-id cirros-0.3.4-x86_64-disk --name boot-vol
$ nova boot --boot-volume  --flavor t1.nano-2-e inst-1
$ nova image-create inst-1 snap-1

3 Boot an instace from the snapshot
$ nova boot --image snap-1 --flavor t1.nano-2-e inst-2

4 Resize the instance
$ nova resize inst-2 t1.nano-1-e

5 Check status of the instance
$ nova list

Expected status: VERIFY_RESIZE
Actual status: ACITVE

Environment:
DevStack on current (the last Nova commit 
a7efa47ec91479c6cc77087cd5b86d2bbf5a0654) Newton OpenStack.

n-cpu.log fragment:

[req-4de3bbd2-a717-4f76-bca0-607573ae46b9 admin admin] Exception during message 
handling
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 
133, in _process_incoming
res = self.dispatcher.dispatch(message)
...
  File "/opt/stack/nova/nova/compute/manager.py", line 6464, in 
_error_out_instance_on_exception
raise error.inner_exception
ResizeError: Resize error: Unable to resize disk down.

** 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/1596957

Title:
  Cannot resize down instance booted from volume backed snapshot with
  ephemeral

Status in OpenStack Compute (nova):
  New

Bug description:
  If an instance is booted from a volume backed snapshot with
  ephemeral(s), it cannot be resized down to a flawor with disk size is
  lesser than original flavor disk size.

  Steps to reproduce:

  1 Prepare flavors
  $ nova flavor-create t1.nano-2-e auto 64 2 1 --ephemeral 1
  $ nova flavor-create t1.nano-1-e auto 64 1 1 --ephemeral 1

  2 Prepare a volume backed snapshot
  $ cinder create 2 --image-id cirros-0.3.4-x86_64-disk --name boot-vol
  $ nova boot --boot-volume  --flavor t1.nano-2-e inst-1
  $ nova image-create inst-1 snap-1

  3 Boot an instace from the snapshot
  $ nova boot --image snap-1 --flavor t1.nano-2-e inst-2

  4 Resize the instance
  $ nova resize inst-2 t1.nano-1-e

  5 Check status of the instance
  $ nova list

  Expected status: VERIFY_RESIZE
  Actual status: ACITVE

  Environment:
  DevStack on current (the last Nova commit 
a7efa47ec91479c6cc77087cd5b86d2bbf5a0654) Newton OpenStack.

  n-cpu.log fragment:
  
  [req-4de3bbd2-a717-4f76-bca0-607573ae46b9 admin admin] Exception during 
message handling
  Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 
133, in _process_incoming
  res = self.dispatcher.dispatch(message)
  ...
File "/opt/stack/nova/nova/compute/manager.py", line 6464, in 
_error_out_instance_on_exception
  raise error.inner_exception
  ResizeError: Resize error: Unable to resize disk down.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1596957/+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 1489442] Re: Invalid order of volumes with adding a volume in boot operation

[Feodor Tersin]

Well,  if all you guys say this is not a bug, it's not a bug. But it's
sadly that Nova cannot guarantee device names even in this simple case.

** Changed in: nova
   Status: New => Invalid

** Changed in: nova
 Assignee: Feodor Tersin (ftersin) => (unassigned)

-- 
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/1489442

Title:
  Invalid order of volumes with adding a volume in boot operation

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  If an image has several volume in bdm, and a user adds one more volume
  for boot operation, then the new volume is not just added to a volume
  list, but becomes the second device. This can lead to problems if the
  image root device has various soft which settings point to other
  volumes.

  For example:
  1 the image is a snapshot of a volume backed instance which had vda and vdb 
volumes
  2 the instance had an sql server, which used both vda and vdb for its database
  3 if a user runs a new instance from the image, either device names are 
restored (with xen), or they're reassigned (libvirt) to the same names, because 
the order of devices, which are passed in libvirt, is the same as it was for 
the original instance
  4 if a user runs a new instance, adding a new volume, the volume list becomes 
vda, new, vdb
  5 in this case libvirt reassings device names to vda=vda, new=vdb, vdb=vdc
  6 as a result the sql server will not find its data on vdb

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1489442/+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 1489442] Re: Invalid order of volumes with adding a volume in boot operation

[Feodor Tersin]

@Nikola,  the problem is not about device names, but about consistency
and workability of volume backed instance snapshots.

Should we support a use case:
1 A user snapshots his volume backed instance which has more than one volume.
2 A user creates a new instance from the snapshot.
3 All services of guest OS work fine.

I think we should, otherwise snapshots of volume backed instances are useless 
for such instances. But this leads us to need to guarantee the stability of 
device names in the custom case.
Now we support this use case.

We support a use case:
1 A user creates an instance from volume backed image, adding a new volume.
2 The instance has the additional volume attached.

What about a combined use case:
1 A user snapshots his volume backed instance which has more than one volume.
2 A user creates a new instance from the snapshot, adding a new volume.
3 The instance has the additional volume attached.
4 All services of guest OS work fine.

To have Nova consistent we should support this use case as well. Any
objections?

As for fs labels, as i understand they could be usefull from outside
only, not from inside an instance (guest OS).

** Changed in: nova
   Status: Invalid => 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/1489442

Title:
  Invalid order of volumes with adding a volume in boot operation

Status in OpenStack Compute (nova):
  New

Bug description:
  If an image has several volume in bdm, and a user adds one more volume
  for boot operation, then the new volume is not just added to a volume
  list, but becomes the second device. This can lead to problems if the
  image root device has various soft which settings point to other
  volumes.

  For example:
  1 the image is a snapshot of a volume backed instance which had vda and vdb 
volumes
  2 the instance had an sql server, which used both vda and vdb for its database
  3 if a user runs a new instance from the image, either device names are 
restored (with xen), or they're reassigned (libvirt) to the same names, because 
the order of devices, which are passed in libvirt, is the same as it was for 
the original instance
  4 if a user runs a new instance, adding a new volume, the volume list becomes 
vda, new, vdb
  5 in this case libvirt reassings device names to vda=vda, new=vdb, vdb=vdc
  6 as a result the sql server will not find its data on vdb

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1489442/+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 1489442] [NEW] Invalid order of volumes with adding a volume in boot operation

[Feodor Tersin]

Public bug reported:

If an image has several volume in bdm, and a user adds one more volume
for boot operation, then the new volume is not just added to a volume
list, but becomes the second device. This can lead to problems if the
image root device has various soft which settings point to other
volumes.

For example:
1 the image is a snapshot of a volume backed instance which had vda and vdb 
volumes
2 the instance had an sql server, which used both vda and vdb for its database
3 if a user runs a new instance from the image, either device names are 
restored (with xen), or they're reassigned (libvirt) to the same names, because 
the order of devices, which are passed in libvirt, is the same as it was for 
the original instance
4 if a user runs a new instance, adding a new volume, the volume list becomes 
vda, new, vdb
5 in this case libvirt reassings device names to vda=vda, new=vdb, vdb=vdc
6 as a result the sql server will not find its data on vdb

** 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/1489442

Title:
  Invalid order of volumes with adding a volume in boot operation

Status in OpenStack Compute (nova):
  New

Bug description:
  If an image has several volume in bdm, and a user adds one more volume
  for boot operation, then the new volume is not just added to a volume
  list, but becomes the second device. This can lead to problems if the
  image root device has various soft which settings point to other
  volumes.

  For example:
  1 the image is a snapshot of a volume backed instance which had vda and vdb 
volumes
  2 the instance had an sql server, which used both vda and vdb for its database
  3 if a user runs a new instance from the image, either device names are 
restored (with xen), or they're reassigned (libvirt) to the same names, because 
the order of devices, which are passed in libvirt, is the same as it was for 
the original instance
  4 if a user runs a new instance, adding a new volume, the volume list becomes 
vda, new, vdb
  5 in this case libvirt reassings device names to vda=vda, new=vdb, vdb=vdc
  6 as a result the sql server will not find its data on vdb

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1489442/+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 1485059] [NEW] bdm image property should overload 'mappings' one for instance launch

[Feodor Tersin]

Public bug reported:

If an image has settings for the same device in both 'mappings' and
'block_device_mapping' properties, the last one should be used for
instance launch. But currently 'mappings' takes precedence.

=
Steps to reproduce:

1 Create a flavor with ephemeral disk.
openstack flavor create m1.nano-ephemeral --id 142 --ram 64 --ephemeral 1

2 Set mapping property in an image:
openstack image set --property mappings='[{device: vdb, virtual: 
ephemeral0}]' cirros-0.3.4-x86_64-uec

3 Check expected mappings:
euca-describe-images
IMAGEami-0001...
BLOCKDEVICEMAPPING/dev/vdb

3 Create a volume:
openstack volume create empty --size 1

4 Create a snapshot:
openstack snapshot create empty --name empty
| Field   | Value|
| id  | af84c37e-3521-435f-9976-e45aaf7fa2c7 |

5 Set bdm property in the image with the snapshot id and the same device name:
openstack image set --property block_device_mapping='[{device_name: 
/dev/vdb, boot_index: -1, source_type: snapshot, destination_type: 
volume, volume_size: 1, delete_on_termination: true, snapshot_id: 
af84c37e-3521-435f-9976-e45aaf7fa2c7}]' --property bdm_v2=true 
cirros-0.3.4-x86_64-uec

6 Check expected mappings:
euca-describe-images
IMAGEami-0001...
BLOCKDEVICEMAPPING/dev/vdbsnap-00011true

Here we see that bdm overloads mappings.

7 Boot an instance with the image:
nova boot --flavor m1.nano-ephemeral --image cirros-0.3.4-x86_64-uec inst

8 Wait active state of the instance and view its volumes:
nova show inst
| Property | Value  
|
| os-extended-volumes:volumes_attached | [] 
|

=
Actual result: no volume is attached to the instance.
Expected result: an id of an attached volume.

=
Since Nova EC2 has not been changed for a long time, it still processes these 
properties in right order. So these steps use EC2 API to display expected 
results.
Also see _setUpImageSet in test_cloud.py.  Pay  attention to mapping1, 
block_device_mapping1, _expected_bdms1 vars. Tests ensures that bdm overloads 
mappings for showing images.

The behavior is broken by https://review.openstack.org/#/c/83805
See there in L636 of api.py:
if image_mapping:
image_defined_bdms += self._prepare_image_mapping(
instance_type, image_mapping)

Compare with left side's L1163:
for mapping in (image_mapping, block_device_mapping):
if not mapping:
continue
self._update_block_device_mapping(context,
instance_type, instance_uuid, mapping)

I think it's safe to restore the old behavior.

** Affects: nova
 Importance: Undecided
 Status: New

** Description changed:

  If an image has settings for the same device in both 'mappings' and
  'block_device_mapping' properties, the last one should be used for
  instance launch. But currently 'mappings' takes precedence.
  
  =
  Steps to reproduce:
  
  1 Create a flavor with ephemeral disk.
  openstack flavor create m1.nano-ephemeral --id 142 --ram 64 --ephemeral 1
  
  2 Set mapping property in an image:
  openstack image set --property mappings='[{device: vdb, virtual: 
ephemeral0}]' cirros-0.3.4-x86_64-uec
  
  3 Check expected mappings:
  euca-describe-images
  IMAGEami-0001...
  BLOCKDEVICEMAPPING/dev/vdb
  
  3 Create a volume:
  openstack volume create empty --size 1
  
  4 Create a snapshot:
  openstack snapshot create empty --name empty
- +-+--+
  | Field   | Value|
- +-+--+
  | id  | af84c37e-3521-435f-9976-e45aaf7fa2c7 |
  
  5 Set bdm property in the image with the snapshot id and the same device name:
  openstack image set --property block_device_mapping='[{device_name: 
/dev/vdb, boot_index: -1, source_type: snapshot, destination_type: 
volume, volume_size: 1, delete_on_termination: true, snapshot_id: 
af84c37e-3521-435f-9976-e45aaf7fa2c7}]' --property bdm_v2=true 
cirros-0.3.4-x86_64-uec
  
  6 Check expected mappings:
  euca-describe-images
  IMAGEami-0001...
  BLOCKDEVICEMAPPING/dev/vdbsnap-00011true
  
  Here we see that bdm overloads mappings.
  
  7 Boot an instance with the image:
  nova boot --flavor m1.nano --image cirros-0.3.4-x86_64-uec inst
  
  8 Wait active state of the instance and view its volumes:
  nova show inst
- 
+--++
  | Property | Value
  |

[Yahoo-eng-team] [Bug 1481220] [NEW] Cannot boot from volume-backed instance snapshot

[Feodor Tersin]

Public bug reported:

Since that https://review.openstack.org/#/c/188789/ is merged, Nova
fails to boot an instance from a volume-backed instance snapshot.

Steps to reproduce against DevStack:
1 boot an instance from a volume:
nova boot inst --block-device 
source=image,dest=volume,size=1,bootindex=0,id=xxx --flavor m1.nano

2 create a volume-backed snapshot
nova image-create inst volback

3 boot a new instance from the snapshot
nova boot inst1 --image volback --flavor m1.nano

Expected result: the new instance attributes.
Actual result:
ERROR (ClientException): The server has either erred or is incapable of 
performing the requested operation. (HTTP 500)

n-api log:
   File /opt/stack/nova/nova/compute/api.py, line 1488, in create
 check_server_group_quota=check_server_group_quota)
   File /opt/stack/nova/nova/compute/api.py, line 1097, in _create_instance
 auto_disk_config, reservation_id, max_count)
   File /opt/stack/nova/nova/compute/api.py, line 854, in 
_validate_and_build_base_options
 image_meta = objects.ImageMeta.from_dict(boot_meta)
   File /opt/stack/nova/nova/objects/image_meta.py, line 91, in from_dict
 return cls(**image_meta)
   File /opt/stack/nova/nova/objects/base.py, line 188, in __init__
 setattr(self, key, kwargs[key])
   File /usr/local/lib/python2.7/dist-packages/oslo_versionedobjects/base.py, 
line 70, in setter
 field_value = field.coerce(self, name, value)
   File 
/usr/local/lib/python2.7/dist-packages/oslo_versionedobjects/fields.py, line 
184, in coerce
 return self._null(obj, attr)
   File 
/usr/local/lib/python2.7/dist-packages/oslo_versionedobjects/fields.py, line 
162, in _null
 raise ValueError(_(Field `%s' cannot be None) % attr)
 ValueError: Field `container_format' cannot be None

** Affects: nova
 Importance: Undecided
 Assignee: Feodor Tersin (ftersin)
 Status: New

** Changed in: nova
 Assignee: (unassigned) = Feodor Tersin (ftersin)

-- 
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/1481220

Title:
  Cannot boot from volume-backed instance snapshot

Status in OpenStack Compute (nova):
  New

Bug description:
  Since that https://review.openstack.org/#/c/188789/ is merged, Nova
  fails to boot an instance from a volume-backed instance snapshot.

  Steps to reproduce against DevStack:
  1 boot an instance from a volume:
  nova boot inst --block-device 
source=image,dest=volume,size=1,bootindex=0,id=xxx --flavor m1.nano

  2 create a volume-backed snapshot
  nova image-create inst volback

  3 boot a new instance from the snapshot
  nova boot inst1 --image volback --flavor m1.nano

  Expected result: the new instance attributes.
  Actual result:
  ERROR (ClientException): The server has either erred or is incapable of 
performing the requested operation. (HTTP 500)

  n-api log:
 File /opt/stack/nova/nova/compute/api.py, line 1488, in create
   check_server_group_quota=check_server_group_quota)
 File /opt/stack/nova/nova/compute/api.py, line 1097, in _create_instance
   auto_disk_config, reservation_id, max_count)
 File /opt/stack/nova/nova/compute/api.py, line 854, in 
_validate_and_build_base_options
   image_meta = objects.ImageMeta.from_dict(boot_meta)
 File /opt/stack/nova/nova/objects/image_meta.py, line 91, in from_dict
   return cls(**image_meta)
 File /opt/stack/nova/nova/objects/base.py, line 188, in __init__
   setattr(self, key, kwargs[key])
 File 
/usr/local/lib/python2.7/dist-packages/oslo_versionedobjects/base.py, line 
70, in setter
   field_value = field.coerce(self, name, value)
 File 
/usr/local/lib/python2.7/dist-packages/oslo_versionedobjects/fields.py, line 
184, in coerce
   return self._null(obj, attr)
 File 
/usr/local/lib/python2.7/dist-packages/oslo_versionedobjects/fields.py, line 
162, in _null
   raise ValueError(_(Field `%s' cannot be None) % attr)
   ValueError: Field `container_format' cannot be None

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1481220/+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 1481164] [NEW] Invalid root device name for volume-backed instances with libvirt

[Feodor Tersin]

Public bug reported:

Since that https://review.openstack.org/#/c/189632/ is merged, root
device name of volume backed instances is /dev/vdb with libvirt.

Steps to reproduce against DevStack:
1 Boot an instance:
nova --block-device source=image,dest=volume,size=1,bootindex=0,id=xxx 
--flavor m1.nano inst
where xxx is an image id.

2 Look at the device name:
openstack volume list

Expected value: /dev/vda
Actual value: /dev/vdb

Inside guest OS the volume is displayed as /dev/vda.

** Affects: nova
 Importance: Undecided
 Assignee: Feodor Tersin (ftersin)
 Status: In Progress

-- 
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/1481164

Title:
  Invalid root device name for volume-backed instances with libvirt

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  Since that https://review.openstack.org/#/c/189632/ is merged, root
  device name of volume backed instances is /dev/vdb with libvirt.

  Steps to reproduce against DevStack:
  1 Boot an instance:
  nova --block-device source=image,dest=volume,size=1,bootindex=0,id=xxx 
--flavor m1.nano inst
  where xxx is an image id.

  2 Look at the device name:
  openstack volume list

  Expected value: /dev/vda
  Actual value: /dev/vdb

  Inside guest OS the volume is displayed as /dev/vda.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1481164/+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 1439820] [NEW] EC2 API fails to create a snapshot of a volume backed instance

[Feodor Tersin]

Public bug reported:

EC2 API fails to create a snapshot of a volume backed instance

It's reproduced with current (~Kilo-3) devstack.

Steps to reproduce:

$ nova boot inst --block-device 
id=cirros,source=image,dest=volume,bootindex=0,size=1--flavor m1.nano
$ euca-create-image ec2-instance-id -n volback-ec2

Returns:
euca-create-image: error (AttributeError): Unknown error occurred.

n-api logs:
Unexpected AttributeError raised: 'NoneType' object has no attribute 'split'
EC2 error response: AttributeError: Unknown error occurred. ec2_error_response 
/opt/stack/nova/nova/api/ec2/faults.py:29
0.748414s 169.254.5.50 POST / CloudController:CreateImage 500 [euca2ools/3.0.1 
(CPython 2.7.6; Linux 3.13.0-48-generic; x86_64) requestbuilder/0.1.0-beta1 
requests/2.2.1] application/x-www-form-urlencoded text/xml

EC2 API layer tries to construct metadata for a snapshot from an
instance image, but it is None. EC2 API doesn't expect this.

** 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/1439820

Title:
  EC2 API fails to create a snapshot of a volume backed instance

Status in OpenStack Compute (Nova):
  New

Bug description:
  EC2 API fails to create a snapshot of a volume backed instance

  It's reproduced with current (~Kilo-3) devstack.

  Steps to reproduce:

  $ nova boot inst --block-device 
id=cirros,source=image,dest=volume,bootindex=0,size=1--flavor m1.nano
  $ euca-create-image ec2-instance-id -n volback-ec2

  Returns:
  euca-create-image: error (AttributeError): Unknown error occurred.

  n-api logs:
  Unexpected AttributeError raised: 'NoneType' object has no attribute 'split'
  EC2 error response: AttributeError: Unknown error occurred. 
ec2_error_response /opt/stack/nova/nova/api/ec2/faults.py:29
  0.748414s 169.254.5.50 POST / CloudController:CreateImage 500 
[euca2ools/3.0.1 (CPython 2.7.6; Linux 3.13.0-48-generic; x86_64) 
requestbuilder/0.1.0-beta1 requests/2.2.1] application/x-www-form-urlencoded 
text/xml

  EC2 API layer tries to construct metadata for a snapshot from an
  instance image, but it is None. EC2 API doesn't expect this.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1439820/+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 1439819] [NEW] Fail to create a snapshot of an instance booted from a volume backed snapshot

[Feodor Tersin]

Public bug reported:

Fail to create a snapshot of an instance booted from a volume backed
snapshot.

It's reproduced with current (~Kilo-3) devstack.

Steps to reproduce:

$ nova boot inst --block-device 
id=cirros,source=image,dest=volume,bootindex=0,size=1--flavor m1.nano
$ nova image-create inst volback
$ nova boot inst-2 --image volback --flavor m1.nano
$ nova image-create inst-2 volback-2

Response:
ERROR (BadRequest): html
 head
  title400 Bad Request/title
 /head
 body
  h1400 Bad Request/h1
  Invalid disk format 'None' for image.br /br /

 /body
/html (HTTP 400) (HTTP 400)

The reason is that container_format and disk_format properties, which
are passed to glance to create 'volback-2' image, are derived from
'volback' image, but they should be absent to create a new snapshot.

** 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/1439819

Title:
  Fail to create a snapshot of an instance booted from a volume backed
  snapshot

Status in OpenStack Compute (Nova):
  New

Bug description:
  Fail to create a snapshot of an instance booted from a volume backed
  snapshot.

  It's reproduced with current (~Kilo-3) devstack.

  Steps to reproduce:

  $ nova boot inst --block-device 
id=cirros,source=image,dest=volume,bootindex=0,size=1--flavor m1.nano
  $ nova image-create inst volback
  $ nova boot inst-2 --image volback --flavor m1.nano
  $ nova image-create inst-2 volback-2

  Response:
  ERROR (BadRequest): html
   head
title400 Bad Request/title
   /head
   body
h1400 Bad Request/h1
Invalid disk format 'None' for image.br /br /

   /body
  /html (HTTP 400) (HTTP 400)

  The reason is that container_format and disk_format properties, which
  are passed to glance to create 'volback-2' image, are derived from
  'volback' image, but they should be absent to create a new snapshot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1439819/+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 1384347] [NEW] Couldn't run instance with existing port when default security group is absent

[Feodor Tersin]

Public bug reported:

If default security group in tenant is deleted (admin has appropriate
permissions) then launching an instance with Neutron port fails at
allocate network resources stage:

ERROR nova.compute.manager [-] Instance failed network setup after 1 attempt(s)
TRACE nova.compute.manager Traceback (most recent call last):
TRACE nova.compute.manager   File /opt/stack/nova/nova/compute/manager.py, 
line 1528, in _allocate_network_async
TRACE nova.compute.manager dhcp_options=dhcp_options)
TRACE nova.compute.manager   File 
/opt/stack/nova/nova/network/neutronv2/api.py, line 294, in 
allocate_for_instance
TRACE nova.compute.manager security_group_id=security_group)
TRACE nova.compute.manager SecurityGroupNotFound: Security group default not 
found.

Steps to reproduce:
0. Delete the default security group with admin account.
1. Create custom security group
2. Create a network and a subnet
3. Create a port in the subnet with the custom security group
4. Launch an instance with the port (and don't specify any security group)

Launch command is accepted successfully, but 'nova show' command returns
the instance in error state.

** 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/1384347

Title:
  Couldn't run instance with existing port when default security group
  is absent

Status in OpenStack Compute (Nova):
  New

Bug description:
  If default security group in tenant is deleted (admin has appropriate
  permissions) then launching an instance with Neutron port fails at
  allocate network resources stage:

  ERROR nova.compute.manager [-] Instance failed network setup after 1 
attempt(s)
  TRACE nova.compute.manager Traceback (most recent call last):
  TRACE nova.compute.manager   File /opt/stack/nova/nova/compute/manager.py, 
line 1528, in _allocate_network_async
  TRACE nova.compute.manager dhcp_options=dhcp_options)
  TRACE nova.compute.manager   File 
/opt/stack/nova/nova/network/neutronv2/api.py, line 294, in 
allocate_for_instance
  TRACE nova.compute.manager security_group_id=security_group)
  TRACE nova.compute.manager SecurityGroupNotFound: Security group default not 
found.

  Steps to reproduce:
  0. Delete the default security group with admin account.
  1. Create custom security group
  2. Create a network and a subnet
  3. Create a port in the subnet with the custom security group
  4. Launch an instance with the port (and don't specify any security group)

  Launch command is accepted successfully, but 'nova show' command
  returns the instance in error state.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1384347/+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 1371424] [NEW] EC2 API does not support filters

[Feodor Tersin]

Public bug reported:

Each AWS describe operation has common and some custom filter parameters
to filter result set by various object attributes. But Nova EC2 supports
filters by object ids only.

I found similar ancient bug https://bugs.launchpad.net/nova/+bug/734912,
but it's closed with 'invalid' resolution. As i understand it refers to
a blueprint which proposes to implement this feature by enhancement of
native Nova filter capability. But there was no activity in this
blueprint for the last 3 years.

I believe we could implement EC2 filters in EC2 layer mostly, using the
existing filtering capabilities of OS services (Nova, Glance, Cinder).
If insufficient performance of filtering operation by some attribute
will be found later, we will optimize it by moving filtering by this
attribute to an appropriate OS service.

** 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/1371424

Title:
  EC2 API does not support filters

Status in OpenStack Compute (Nova):
  New

Bug description:
  Each AWS describe operation has common and some custom filter
  parameters to filter result set by various object attributes. But Nova
  EC2 supports filters by object ids only.

  I found similar ancient bug
  https://bugs.launchpad.net/nova/+bug/734912, but it's closed with
  'invalid' resolution. As i understand it refers to a blueprint which
  proposes to implement this feature by enhancement of native Nova
  filter capability. But there was no activity in this blueprint for the
  last 3 years.

  I believe we could implement EC2 filters in EC2 layer mostly, using
  the existing filtering capabilities of OS services (Nova, Glance,
  Cinder). If insufficient performance of filtering operation by some
  attribute will be found later, we will optimize it by moving filtering
  by this attribute to an appropriate OS service.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1371424/+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 1370901] [NEW] Nova EC2 doesn't create empty volume while launching an instance

[Feodor Tersin]

Public bug reported:

AWS is able to create and attach a new empty volume while launching an 
instance. See 
http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/ApiReference-cmd-RunInstances.html:
---
To create an empty Amazon EBS volume, omit the snapshot ID and specify a volume 
size instead. For example: /dev/sdh=:20.
---
This can be set by run_instances parameters, and by image block device mapping 
structure.

But Nova EC2 isn't able to do this:

$ euca-run-instances --instance-type m1.nano ami-0001 
--block-device-mapping /dev/vdd=:1
euca-run-instances: error (InvalidBDMFormat): Block Device Mapping is Invalid: 
Unrecognized legacy format.

** 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/1370901

Title:
  Nova EC2 doesn't create empty volume while launching an instance

Status in OpenStack Compute (Nova):
  New

Bug description:
  AWS is able to create and attach a new empty volume while launching an 
instance. See 
http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/ApiReference-cmd-RunInstances.html:
  ---
  To create an empty Amazon EBS volume, omit the snapshot ID and specify a 
volume size instead. For example: /dev/sdh=:20.
  ---
  This can be set by run_instances parameters, and by image block device 
mapping structure.

  But Nova EC2 isn't able to do this:

  $ euca-run-instances --instance-type m1.nano ami-0001 
--block-device-mapping /dev/vdd=:1
  euca-run-instances: error (InvalidBDMFormat): Block Device Mapping is 
Invalid: Unrecognized legacy format.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1370901/+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 1371046] [NEW] No type check for resource-id value in EC2 describe_tags filter

[Feodor Tersin]

Public bug reported:

$ euca-describe-tags --filter resource-id=vol-nnn
returns tags for ami-nnn instance.

For example:
$ euca-describe-tags
TAG i-000e  instancexxx yyy

$ euca-describe-tags --filter resource-id=vol-000e
TAG i-000e  instancexxx yyy

** 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/1371046

Title:
  No type check for resource-id value in EC2 describe_tags filter

Status in OpenStack Compute (Nova):
  New

Bug description:
  $ euca-describe-tags --filter resource-id=vol-nnn
  returns tags for ami-nnn instance.

  For example:
  $ euca-describe-tags
  TAG   i-000e  instancexxx yyy

  $ euca-describe-tags --filter resource-id=vol-000e
  TAG   i-000e  instancexxx yyy

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1371046/+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 1370384] [NEW] Cannot expand root volume by EC2 API

[Feodor Tersin]

Public bug reported:

AWS provides a scenario to expand volumes of an instance 
(http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-expand-volume.html). It 
consist of:
1 Stop the instance
2 Create a snapshot of the volume
3 Create a new volume from the snapshot
4 Detach the old volum
5 Attach the new volume using the same device name
6 Start the instance

In Nova this works for non-root devices, but doesn't for a root device.

Now in current version (Juno) since
https://review.openstack.org/#/c/75552/ was merged it's not able to
detach root volume at all.

$ nova volume-detach inst 02f60d80-47ee-47ed-a795-cb4d05f5103e
ERROR (Forbidden): Can't detach root device volume (HTTP 403) (Request-ID: 
req-e25134dc-1330-4fe1-9d21-abc274e75a1d)

Before this commit it was able, but it was unable to attach the root
volume back.

** 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/1370384

Title:
  Cannot expand root volume by EC2 API

Status in OpenStack Compute (Nova):
  New

Bug description:
  AWS provides a scenario to expand volumes of an instance 
(http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-expand-volume.html). It 
consist of:
  1 Stop the instance
  2 Create a snapshot of the volume
  3 Create a new volume from the snapshot
  4 Detach the old volum
  5 Attach the new volume using the same device name
  6 Start the instance

  In Nova this works for non-root devices, but doesn't for a root
  device.

  Now in current version (Juno) since
  https://review.openstack.org/#/c/75552/ was merged it's not able to
  detach root volume at all.

  $ nova volume-detach inst 02f60d80-47ee-47ed-a795-cb4d05f5103e
  ERROR (Forbidden): Can't detach root device volume (HTTP 403) (Request-ID: 
req-e25134dc-1330-4fe1-9d21-abc274e75a1d)

  Before this commit it was able, but it was unable to attach the root
  volume back.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1370384/+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 1370177] [NEW] Lack of EC2 image attributes for volume backed snapshot.

[Feodor Tersin]

Public bug reported:

For EBS images AWS returns device names, volume sizes, delete on
termination flags in block device mapping structure.

$ euca-describe-images ami-d13845e1
IMAGE   ami-d13845e1amazon/amzn-ami-hvm-2014.03.2.x86_64-ebsamazon  
available   public  x86_64  machine ebs hvm 
xen
BLOCKDEVICEMAPPING  /dev/xvda   snap-d15cde24   8   true

The same in xml form:
blockDeviceMapping
item
deviceName/dev/xvda/deviceName
ebs
snapshotIdsnap-d15cde24/snapshotId
volumeSize8/volumeSize
deleteOnTerminationtrue/deleteOnTermination
volumeTypestandard/volumeType
/ebs
/item
/blockDeviceMapping

But Nova didn't do it now:

$ euca-describe-images ami-000a
IMAGE   ami-000aNone (sn-in)ef3ddd7aa4b24cda974200baef02730b
available   private machine aki-0002ari-0003
instance-store  
BLOCKDEVICEMAPPING  snap-0005

The same in xml form:
  blockDeviceMapping
item
  ebs
snapshotIdsnap-0005/snapshotId
  /ebs
/item
  /blockDeviceMapping

NB. In Grizzly device names and delete on termination flags was returned. It 
was changed by 
https://github.com/openstack/nova/commit/33e3d4c6b9e0b11500fe47d861110be1c1981572
Now these attributes are not stored in instance snapshots, so there is no way 
to output them.

Device name is most critical attribute. Because there is another one 
compatibility issue: Nova isn't able to adjust attributes of volume being 
created at instance launch stage. For example in AWS we can change volume size 
and delete on termination flag of a device by set new values in parameters of 
run instance command. To identify the device in image block device mapping we 
use device name. For example:
euca-run-instances ... -b /dev/vda=:100
runs an instance with vda device increased to 100 GB.
Thus if we haven't device names in images, we haven't a chance to fix this 
compatibility problem.

** 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/1370177

Title:
  Lack of EC2 image attributes for volume backed snapshot.

Status in OpenStack Compute (Nova):
  New

Bug description:
  For EBS images AWS returns device names, volume sizes, delete on
  termination flags in block device mapping structure.

  $ euca-describe-images ami-d13845e1
  IMAGE ami-d13845e1amazon/amzn-ami-hvm-2014.03.2.x86_64-ebsamazon  
available   public  x86_64  machine ebs hvm 
xen
  BLOCKDEVICEMAPPING/dev/xvda   snap-d15cde24   8   true

  The same in xml form:
  blockDeviceMapping
  item
  deviceName/dev/xvda/deviceName
  ebs
  snapshotIdsnap-d15cde24/snapshotId
  volumeSize8/volumeSize
  deleteOnTerminationtrue/deleteOnTermination
  volumeTypestandard/volumeType
  /ebs
  /item
  /blockDeviceMapping

  But Nova didn't do it now:

  $ euca-describe-images ami-000a
  IMAGE ami-000aNone (sn-in)ef3ddd7aa4b24cda974200baef02730b
available   private machine aki-0002ari-0003
instance-store  
  BLOCKDEVICEMAPPINGsnap-0005

  The same in xml form:
blockDeviceMapping
  item
ebs
  snapshotIdsnap-0005/snapshotId
/ebs
  /item
/blockDeviceMapping

  NB. In Grizzly device names and delete on termination flags was returned. It 
was changed by 
https://github.com/openstack/nova/commit/33e3d4c6b9e0b11500fe47d861110be1c1981572
  Now these attributes are not stored in instance snapshots, so there is no way 
to output them.

  Device name is most critical attribute. Because there is another one 
compatibility issue: Nova isn't able to adjust attributes of volume being 
created at instance launch stage. For example in AWS we can change volume size 
and delete on termination flag of a device by set new values in parameters of 
run instance command. To identify the device in image block device mapping we 
use device name. For example:
  euca-run-instances ... -b /dev/vda=:100
  runs an instance with vda device increased to 100 GB.
  Thus if we haven't device names in images, we haven't a chance to fix this 
compatibility problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1370177/+subscriptions

-- 
Mailing list: 

[Yahoo-eng-team] [Bug 1370250] [NEW] Can not set volume attributes at instance launch by EC2 API

[Feodor Tersin]

Public bug reported:

AWS allows to change block device attributes (such as volume size,
delete on termination behavior, existence) at instance launch.

For example, image xxx has devices:
vda, size 10, delete on termination
vdb, size 100, delete on termination
vdc, size 100, delete on termination
We can run an instance by
euca-run-instances ... xxx -b /dev/vda=:20 -b /dev/vdb=::false -b /dev/vdc=none
to get the instance with devices:
vda, size 20, delete on termination
vdb, size 100, not delete on termination

For Nova we get now:
$ euca-run-instances --instance-type m1.nano -b /dev/vda=::true ami-000a
euca-run-instances: error (InvalidBDMFormat): Block Device Mapping is Invalid: 
Unrecognized legacy format.

** 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/1370250

Title:
  Can not set volume attributes at instance launch by EC2 API

Status in OpenStack Compute (Nova):
  New

Bug description:
  AWS allows to change block device attributes (such as volume size,
  delete on termination behavior, existence) at instance launch.

  For example, image xxx has devices:
  vda, size 10, delete on termination
  vdb, size 100, delete on termination
  vdc, size 100, delete on termination
  We can run an instance by
  euca-run-instances ... xxx -b /dev/vda=:20 -b /dev/vdb=::false -b 
/dev/vdc=none
  to get the instance with devices:
  vda, size 20, delete on termination
  vdb, size 100, not delete on termination

  For Nova we get now:
  $ euca-run-instances --instance-type m1.nano -b /dev/vda=::true ami-000a
  euca-run-instances: error (InvalidBDMFormat): Block Device Mapping is 
Invalid: Unrecognized legacy format.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1370250/+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 1370265] [NEW] Crash on describing EC2 volume backed image with multiple devices

[Feodor Tersin]

Public bug reported:

EC2 describe images crashes on volume backed instance snapshot which has
several volumes:

$ euca-describe-images
euca-describe-images: error (KeyError): Unknown error occurred.

Steps to reproduce
1 Create bootable volume
$ cinder create --image image-id size

2 Boot instance from volume
$ nova boot --flavor m1.nano --block-device-mapping /dev/vda=volume_id:::1 
inst

3 Create empty volume
$ cinder create 1

4 Attach the volume to the instance
$ nova volume-attach inst empty-volume-id /dev/vdd

5 Create volume backed snapshot
$ nova image-create inst sn-in

6 Describe EC2 images
$ euca-describe-images

** 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/1370265

Title:
  Crash on describing EC2 volume backed image with multiple devices

Status in OpenStack Compute (Nova):
  New

Bug description:
  EC2 describe images crashes on volume backed instance snapshot which
  has several volumes:

  $ euca-describe-images
  euca-describe-images: error (KeyError): Unknown error occurred.

  Steps to reproduce
  1 Create bootable volume
  $ cinder create --image image-id size

  2 Boot instance from volume
  $ nova boot --flavor m1.nano --block-device-mapping /dev/vda=volume_id:::1 
inst

  3 Create empty volume
  $ cinder create 1

  4 Attach the volume to the instance
  $ nova volume-attach inst empty-volume-id /dev/vdd

  5 Create volume backed snapshot
  $ nova image-create inst sn-in

  6 Describe EC2 images
  $ euca-describe-images

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1370265/+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 1370330] [NEW] Cannot attach a volume without '/dev/' prefix by EC2 API

[Feodor Tersin]

Public bug reported:

AWS allows to attach a volume with short device name (without '/dev/'
prefix). But Nova doesn't.

$ euca-attach-volume -i i-0008 -d vdd vol-0003
euca-attach-volume: error (InvalidDevicePath): The supplied device path (vdd) 
is invalid.

** Affects: nova
 Importance: Undecided
 Status: New

** Description changed:

  AWS allows to attach a volume with short device name (without '/dev/'
- prefix). But Nova don't.
+ prefix). But Nova doesn't.
  
  $ euca-attach-volume -i i-0008 -d vdd vol-0003
  euca-attach-volume: error (InvalidDevicePath): The supplied device path (vdd) 
is invalid.

-- 
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/1370330

Title:
  Cannot attach a volume without '/dev/' prefix by EC2 API

Status in OpenStack Compute (Nova):
  New

Bug description:
  AWS allows to attach a volume with short device name (without '/dev/'
  prefix). But Nova doesn't.

  $ euca-attach-volume -i i-0008 -d vdd vol-0003
  euca-attach-volume: error (InvalidDevicePath): The supplied device path (vdd) 
is invalid.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1370330/+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 1370339] [NEW] Cannot register volume backed image by EC2 API

[Feodor Tersin]

Public bug reported:

AWS allows to register a volume backed image. But Nova doesn't:

$ euca-register -n ebs-image --kernel aki-0002 --ramdisk ari-0003 
--root-device-name /dev/vda -b /dev/vda=snap-0006
euca-register: error (HTTPInternalServerError): The server has either erred or 
is incapable of performing the requested operation.

In fact this feature is not implemented in Nova. But this feature is
used in 'Launching an Instance from a Backup' AWS scenario
(http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-launch-
snapshot.html).

** 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/1370339

Title:
  Cannot register volume backed image by EC2 API

Status in OpenStack Compute (Nova):
  New

Bug description:
  AWS allows to register a volume backed image. But Nova doesn't:

  $ euca-register -n ebs-image --kernel aki-0002 --ramdisk ari-0003 
--root-device-name /dev/vda -b /dev/vda=snap-0006
  euca-register: error (HTTPInternalServerError): The server has either erred 
or is incapable of performing the requested operation.

  In fact this feature is not implemented in Nova. But this feature is
  used in 'Launching an Instance from a Backup' AWS scenario
  (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-launch-
  snapshot.html).

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1370339/+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 1355285] [NEW] EC2 attachment set is absent for attaching/detaching volumes

[Feodor Tersin]

Public bug reported:

When volume is attaching AWS reports attachment info:
VOLUME  vol-b6baa9ff 1  us-east-1b  in-use  
2014-08-11T15:34:38.090Z
ATTACHMENT  vol-b6baa9ffi-afcc1f85  /dev/sddattaching   
2014-08-11T15:41:24.000Z

But Nova EC2 doesn't do it:
VOLUME  vol-0001 1  novain-use  
2014-08-10T19:51:06.00
ATTACHMENT  vol-0001NoneNoneNoneNone

** Affects: nova
 Importance: Undecided
 Assignee: Feodor Tersin (ftersin)
 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/1355285

Title:
  EC2 attachment set is absent for attaching/detaching volumes

Status in OpenStack Compute (Nova):
  New

Bug description:
  When volume is attaching AWS reports attachment info:
  VOLUMEvol-b6baa9ff 1  us-east-1b  in-use  
2014-08-11T15:34:38.090Z
  ATTACHMENTvol-b6baa9ffi-afcc1f85  /dev/sddattaching   
2014-08-11T15:41:24.000Z

  But Nova EC2 doesn't do it:
  VOLUMEvol-0001 1  novain-use  
2014-08-10T19:51:06.00
  ATTACHMENTvol-0001NoneNoneNoneNone

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1355285/+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 1325079] [NEW] Invalid error message for snapshot creation in EC2 layer

[Feodor Tersin]

Public bug reported:

Volume snapshots in EC2 can be created only for volumes in some
particular statuses. For other statuses creation an error should be
returned. Current EC2 code doesn't check the statuses and pass the
request to Cinder code. When it fails creating it returns its own native
error which is incorrectly reported further by EC2 layer.

Environment: DevStack

Steps to reproduce:
1 Run from script:
vol=$(euca-create-volume -z nova -s 1 --snapshot snap-xxx | awk -F   '{print 
$2}')
euca-create-snapshot $vol

InvalidInput: Invalid input received: Invalid volume: must be available

If run tthis agains AWS the error output is
IncorrectState: Volume 'vol-xxx' is not in a state where snapshots are allowed.

Note. To reproduce the error on AWS i recommend to get a non-empty
snapshot about 10GB and increase the size parameter in euca-create-
volume.

** Affects: nova
 Importance: Undecided
 Assignee: Feodor Tersin (ftersin)
 Status: New

** Changed in: nova
 Assignee: (unassigned) = Feodor Tersin (ftersin)

-- 
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/1325079

Title:
  Invalid error message for snapshot creation in EC2 layer

Status in OpenStack Compute (Nova):
  New

Bug description:
  Volume snapshots in EC2 can be created only for volumes in some
  particular statuses. For other statuses creation an error should be
  returned. Current EC2 code doesn't check the statuses and pass the
  request to Cinder code. When it fails creating it returns its own
  native error which is incorrectly reported further by EC2 layer.

  Environment: DevStack

  Steps to reproduce:
  1 Run from script:
  vol=$(euca-create-volume -z nova -s 1 --snapshot snap-xxx | awk -F   
'{print $2}')
  euca-create-snapshot $vol

  InvalidInput: Invalid input received: Invalid volume: must be
  available

  If run tthis agains AWS the error output is
  IncorrectState: Volume 'vol-xxx' is not in a state where snapshots are 
allowed.

  Note. To reproduce the error on AWS i recommend to get a non-empty
  snapshot about 10GB and increase the size parameter in euca-create-
  volume.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1325079/+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 1324400] [NEW] Invalid EC2 instance type for a volume backed instance

[Feodor Tersin]

Public bug reported:

Due to nova.virt.driver:LibvirtDriver.get_guest_config prepends instance 
root_device_name with 'dev' prefix, root_device_name may not coincide with 
device_name in block device mapping structure.
In this case describe instances operation reports wrong instance type: 
instance-store instead of ebs.

Environment: DevStack

Steps to reproduce:
1 Create volume backed instance passgin vda as root device name
$ cinder create --image-id xxx 1
$ nova boot --flavor m1.nano --image xxx --block-device-mapping vda=yyy:::1 inst
Note. I used cirros ami image.

2 Describe instances
$ euca-describe-instances
Look on instace type. It must be ebs, but it is instance-store in the output.

Note. If euca-describe-instance crashes on ebs instnce, apply
https://review.openstack.org/#/c/95580/

** Affects: nova
 Importance: Undecided
 Assignee: Feodor Tersin (ftersin)
 Status: New

** Changed in: nova
 Assignee: (unassigned) = Feodor Tersin (ftersin)

-- 
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/1324400

Title:
  Invalid EC2 instance  type for a volume backed instance

Status in OpenStack Compute (Nova):
  New

Bug description:
  Due to nova.virt.driver:LibvirtDriver.get_guest_config prepends instance 
root_device_name with 'dev' prefix, root_device_name may not coincide with 
device_name in block device mapping structure.
  In this case describe instances operation reports wrong instance type: 
instance-store instead of ebs.

  Environment: DevStack

  Steps to reproduce:
  1 Create volume backed instance passgin vda as root device name
  $ cinder create --image-id xxx 1
  $ nova boot --flavor m1.nano --image xxx --block-device-mapping vda=yyy:::1 
inst
  Note. I used cirros ami image.

  2 Describe instances
  $ euca-describe-instances
  Look on instace type. It must be ebs, but it is instance-store in the output.

  Note. If euca-describe-instance crashes on ebs instnce, apply
  https://review.openstack.org/#/c/95580/

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1324400/+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 1323403] Re: ec2-api crashes on describing volume backed snapshot

[Feodor Tersin]

https://review.openstack.org/#/c/95580/

** Project changed: devstack = nova

** Changed in: nova
   Status: New = In Progress

-- 
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/1323403

Title:
  ec2-api crashes on describing volume backed snapshot

Status in OpenStack Compute (Nova):
  In Progress

Bug description:
  If volume backed snapshot is available for an user euca-describe-
  images crashes due to 'unknown server error'.

  Environment: DevStack

  Steps to reproduce:

  1 Create a volume backed snapshot
  $ cinder create --image-id xxx 1
  $ nova boot --flavor m1.nano --image xxx --block-device-mapping 
/dev/vda=yyy:::1 inst

  2 List images to ensure the created snapshot is available.
  $ glance image-list

  3 Describe images by euca2ools
  $ euca-describe-images
  TypeError: Unknown error occurred.

  nova-api.log
  2014-05-26 23:16:18.070 ERROR nova.api.ec2 
[req-105138c5-1b82-42ff-a5fd-4588a4262763 demo demo] Unexpected TypeError 
raised: int() argument must be a string or a number, 
  not 'NoneType'
  2014-05-26 23:16:18.071 DEBUG nova.api.ec2.faults 
[req-105138c5-1b82-42ff-a5fd-4588a4262763 demo demo] EC2 error response: 
TypeError: Unknown error occurred. ec2_error_response 
/opt/stack/nova/nova/api/ec2/faults.py:29

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1323403/+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 1322157] [NEW] Invalid snapshot is created from volume backed instance

[Feodor Tersin]

Public bug reported:

An incorrect snapshot is created from volume backed instance booted from
volume. The snapshot doesn't have disk_format and container_format
attributes. As a result booting from the snapshot fails.

Environment: DevStack

Steps to reproduce:
1 Create bootable volume
$ cinder create --image-id xxx 1
Note. I used cirros-0.3.2-x86_64-uec ami image.

2 Boot instance from volume
$ nova boot --flavor m1.nano --block-device 
id=yyy,source=volume,dest=volume,device=/dev/vda,bootindex=0,shutdown=remove 
inst

3 Create instance snapshot
$ nova image-create inst snap

4 Boot instance from snapshot
$ nova boot --flavor m1.nano --image snap inst1

The last command's output:
ERROR (InternalServerError): The server has either erred or is incapable of 
performing the requested operation. (HTTP 500) (Request-ID: 
req-45cb14af-3d80-4980-945e-1db6f958950b)

Nova api log:
2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack   File 
/opt/stack/nova/nova/image/glance.py, line 277, in show
2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack base_image_meta = 
_translate_from_glance(image)
2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack   File 
/opt/stack/nova/nova/image/glance.py, line 462, in _translate_from_glance
2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack image_meta = 
_extract_attributes(image)
2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack   File 
/opt/stack/nova/nova/image/glance.py, line 530, in _extract_attributes
2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack output[attr] = 
getattr(image, attr)
2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack   File 
/opt/stack/python-glanceclient/glanceclient/openstack/common/apiclient/base.py,
 line 462, in __getattr__
2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack return 
self.__getattr__(k)
2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack   File 
/opt/stack/python-glanceclient/glanceclient/openstack/common/apiclient/base.py,
 line 464, in __getattr__
2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack raise 
AttributeError(k)
2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack AttributeError: 
disk_format

6 Check instance snapshot attributes
$ glance image-show snap
Rows for disk and container format are absent.


The problem is in _action_create_image in 
nova/api/openstack/compute/servers.py. 'not img' branch incorrectly initializes 
image_meta variable.

** 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/1322157

Title:
  Invalid snapshot is created from volume backed instance

Status in OpenStack Compute (Nova):
  New

Bug description:
  An incorrect snapshot is created from volume backed instance booted
  from volume. The snapshot doesn't have disk_format and
  container_format attributes. As a result booting from the snapshot
  fails.

  Environment: DevStack

  Steps to reproduce:
  1 Create bootable volume
  $ cinder create --image-id xxx 1
  Note. I used cirros-0.3.2-x86_64-uec ami image.

  2 Boot instance from volume
  $ nova boot --flavor m1.nano --block-device 
id=yyy,source=volume,dest=volume,device=/dev/vda,bootindex=0,shutdown=remove 
  inst

  3 Create instance snapshot
  $ nova image-create inst snap

  4 Boot instance from snapshot
  $ nova boot --flavor m1.nano --image snap inst1

  The last command's output:
  ERROR (InternalServerError): The server has either erred or is incapable of 
performing the requested operation. (HTTP 500) (Request-ID: 
req-45cb14af-3d80-4980-945e-1db6f958950b)

  Nova api log:
  2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack   File 
/opt/stack/nova/nova/image/glance.py, line 277, in show
  2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack base_image_meta = 
_translate_from_glance(image)
  2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack   File 
/opt/stack/nova/nova/image/glance.py, line 462, in _translate_from_glance
  2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack image_meta = 
_extract_attributes(image)
  2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack   File 
/opt/stack/nova/nova/image/glance.py, line 530, in _extract_attributes
  2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack output[attr] = 
getattr(image, attr)
  2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack   File 
/opt/stack/python-glanceclient/glanceclient/openstack/common/apiclient/base.py,
 line 462, in __getattr__
  2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack return 
self.__getattr__(k)
  2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack   File 
/opt/stack/python-glanceclient/glanceclient/openstack/common/apiclient/base.py,
 line 464, in __getattr__
  2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack raise 
AttributeError(k)
  2014-05-22 15:10:48.084 12610 TRACE nova.api.openstack 

[Yahoo-eng-team] [Bug 1322180] [NEW] Fail to launch an instance from volume by legacy bdm

[Feodor Tersin]

Public bug reported:

Launting an instance from bootable volume passing legacy bdm is
available only using vda (no /dev/ prefix) as root device name. This is
weird restriction. It prevents to create consistent instance data,
because root_device_name instance attribute has /dev/ prefix, but
device_name bdm attribute doesn't.

Environment: DevStack

Steps to reproduce:
1 Create bootable volume
$ cinder create --image-id xxx 1
Note: I used cirros-0.3.2-x86_64-uec ami image.

2 Boot instance from the volume by legacy bdm.
$ nova boot --flavor m1.nano --block-device-mapping /dev/vda=yyy:::1 inst

3 Wait instance status Active, go to instance console and look to 'No
bootable device' message.


The reason is in _get_bdm_image_metadata in nova/compute/api.py. There only 
'vda' devices are processed as root device for legacy bdm.

** 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/1322180

Title:
  Fail to launch an instance from volume by legacy bdm

Status in OpenStack Compute (Nova):
  New

Bug description:
  Launting an instance from bootable volume passing legacy bdm is
  available only using vda (no /dev/ prefix) as root device name. This
  is weird restriction. It prevents to create consistent instance data,
  because root_device_name instance attribute has /dev/ prefix, but
  device_name bdm attribute doesn't.

  Environment: DevStack

  Steps to reproduce:
  1 Create bootable volume
  $ cinder create --image-id xxx 1
  Note: I used cirros-0.3.2-x86_64-uec ami image.

  2 Boot instance from the volume by legacy bdm.
  $ nova boot --flavor m1.nano --block-device-mapping /dev/vda=yyy:::1 inst

  3 Wait instance status Active, go to instance console and look to 'No
  bootable device' message.

  
  The reason is in _get_bdm_image_metadata in nova/compute/api.py. There only 
'vda' devices are processed as root device for legacy bdm.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1322180/+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 1322195] [NEW] Admin creates volume backed instance snapshot in image tenant

[Feodor Tersin]

Public bug reported:

For instance booted from volume with legacy bdm and image (this method is 
documented as workaround in 
http://docs.openstack.org/grizzly/openstack-ops/content/attach_block_storage.html)
 admin user creates instance snapshot in the image tenant rather than current 
tenant.
Created snapshot cannot be used.

Environment: DevStack

Steps to reproduce:
1 Create bootable volume from public image from not current tenant.
For example, use demo tenant in DevStack.
$ cinder create --image-id xxx 1
Note: I used cirros-0.3.2-x86_64-uec ami image.

2 Boot an instance from the volume passing the original image.
$ nova boot --flavor m1.nano --image xxx --block-device-mapping /dev/vda=yyy 
inst

3 Create instance snapshot under admin user
$ nova image-create inst snap

4 List images and make sure there is no the created snapshot.
$ glance image-list

5 List images from the original image tenant and found the snapshot.
$ glance --os-tenant-name nnn image-list


snapshot_volume_backed in nova/compute/api.py receives image in image_meta 
parameter, cleans some attributes, but forgets to deal something with owner 
attribute.

** 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/1322195

Title:
  Admin creates volume backed instance snapshot in image tenant

Status in OpenStack Compute (Nova):
  New

Bug description:
  For instance booted from volume with legacy bdm and image (this method is 
documented as workaround in 
http://docs.openstack.org/grizzly/openstack-ops/content/attach_block_storage.html)
 admin user creates instance snapshot in the image tenant rather than current 
tenant.
  Created snapshot cannot be used.

  Environment: DevStack

  Steps to reproduce:
  1 Create bootable volume from public image from not current tenant.
  For example, use demo tenant in DevStack.
  $ cinder create --image-id xxx 1
  Note: I used cirros-0.3.2-x86_64-uec ami image.

  2 Boot an instance from the volume passing the original image.
  $ nova boot --flavor m1.nano --image xxx --block-device-mapping /dev/vda=yyy 
inst

  3 Create instance snapshot under admin user
  $ nova image-create inst snap

  4 List images and make sure there is no the created snapshot.
  $ glance image-list

  5 List images from the original image tenant and found the snapshot.
  $ glance --os-tenant-name nnn image-list

  
  snapshot_volume_backed in nova/compute/api.py receives image in image_meta 
parameter, cleans some attributes, but forgets to deal something with owner 
attribute.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1322195/+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