Open Stack

On 08/01/16 14:45 +0000, Daniel P. Berrange wrote:
>On Fri, Jan 08, 2016 at 10:01:45AM -0430, Flavio Percoco wrote:
>> On 29/12/15 07:41 -0600, Sam Matzek wrote:
>> >On Thu, Dec 24, 2015 at 7:49 AM, Mikhail Fedosin <mfedosin at mirantis.com> wrote:
>> >>Hello, it's another topic about glance v2 adoption in Nova, but it's
>> >>different from the others. I want to declare that there is a set of commits,
>> >>that make Nova version agnostic and allow to work with both glance apis. The
>> >>idea of the solution is to determine the current api version in the
>> >>beginning and make appropriate requests after.
>> >>(https://review.openstack.org/#/c/228578/,
>> >>https://review.openstack.org/#/c/238309/,
>> >>https://review.openstack.org/#/c/259097/)
>> >>
>> >>Indeed, it requires some additional (and painful) work, but now all tempest
>> >>tests pass in Jenkins.
>> >>
>> >>Note: this thread is not about xenplugin, there is another topic, called
>> >>'Xenplugin + Glance_v2 = Hate'
>> >>
>> >>Here the main issues we faced and how we've solved them:
>> >>
>> >>1. "changes-since" filter for image-list is not supported in v2 api. Steve
>> >>Lewis made a great job and implemented a set of filters with comparison
>> >>operators https://review.openstack.org/#/c/197388/. Filtering by
>> >>'changes-since' is completely similar to 'gte:updated_at'.
>> >>
>> >>2. Filtering by custom properties must have prefix 'property-'. In v2 it's
>> >>not required.
>> >>
>> >>3. V2 states that all custom properties must be image attributes, but Nova
>> >>assumes that they are included in 'properties' dictionary. It's fixed with
>> >>glanceclient's method 'is_base_property(prop_name)', that returns False in
>> >>case of custom property.
>> >>
>> >>4. is_public=True/False is visibility="public"/"private" respectively.
>> >>
>> >>5. Deleting custom image properties in Nova is performed with 'purge_props'
>> >>flag. If it's set to True, then all prop names, that are not included in
>> >>updated data, will be removed. In case of v2 we have to explicitly specify
>> >>prop names in the list param 'remove_props'. To implement this behaviour, if
>> >>'purge_props' is set, we make additional 'get' request to determine the
>> >>existing properties and put in 'remove_prop' list only those, that are not
>> >>in updated_data.
>> >>
>> >>6. My favourite:
>> >>There is an ability to activate an empty image by just providing 'size = 0':
>> >>https://review.openstack.org/#/c/9715/, in this case image will be a
>> >>collection of metadata. Glance v2 doesn't support this "feature" and that's
>> >>why we have to implement a very dirty workaround:
>> >>    * v2 requires, that disk_format and container-format must be set before
>> >>the activation. if these params are not provided to 'create' method then we
>> >>hardcode it to 'qcow2' and 'bare'.
>> >>    * we call 'upload' method with empty data (data = '') to activate image.
>> >>Me (and the rest glance team) think that this image activation with
>> >>zero-size is inconsistent and we won't implement it in v2. So, I'm going to
>> >>ask if Nova really needs this feature and maybe it's possible to make it
>> >>work without it.
>> >
>> >Nova uses this functionality when it creates snapshots of volume
>> >backed instances, that is, instances that only have Cinder volumes
>> >attached and do not have an ephemeral disk.
>> >In this case Nova API creates Cinder snapshots for the Cinder volumes
>> >and builds the block_device_mapping property with block devices that
>> >reference the Cinder snapshots.  Nova activates this image with size=0
>> >because this image does not have a disk and simply refers to the
>> >collection of Cinder snapshots that collectively comprise the binary
>> >image.  Callers of Glance outside of Nova may also use the APIs to
>> >create "block device mapping" images as well that contain references
>> >to Cinder volumes to attach, blank volumes to create, snapshots to
>> >create volumes from, etc during the server creation.  Not having the
>> >ability to create these images with V2 is a loss of function.
>>
>> I disagree. Being able to activate empty images breaks the consistency
>> of Glances API and I don't think it should be considered a feature but
>> a bug. An active image is an image that can be used to *boot* a VM. If
>> the image is empty, you simply can't do that.
>
>NB if an empty image is associated with a kernel/initrd image then it
>could conceptually still be bootable, as the VM could run entirely from
>content contained in the initrd, or the initrd might have activated
>some network accessed root device. Whether this works in practice
>with glance empty images though I don't know. Just from a conceptual
>POV, images don't need to contain any content at all.

Mmmhhh... I was indeed missing something. Philosophically speaking,
though, the image is not really empty but pointing to two other
images, which is basically what happens when we point to a data stored
somewhere.

What's perhaps missing is a formal way to associate the image with a
kernel/initrd image and have it become active.

Hope it makes sense,
Flavio

>
>Regards,
>Daniel
>-- 
>|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
>|: http://libvirt.org              -o-             http://virt-manager.org :|
>|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
>|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160108/1b7206a3/attachment.pgp>