<div dir="ltr">Agreed with Sam, the point 6 is actually very important now for production deployment, as volume-backed instance is very common. Maybe we should keep it until we find a better solution.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 29, 2015 at 9:41 PM, Sam Matzek <span dir="ltr"><<a href="mailto:matzeksam@gmail.com" target="_blank">matzeksam@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Dec 24, 2015 at 7:49 AM, Mikhail Fedosin <<a href="mailto:mfedosin@mirantis.com">mfedosin@mirantis.com</a>> wrote:<br>
> Hello, it's another topic about glance v2 adoption in Nova, but it's<br>
> different from the others. I want to declare that there is a set of commits,<br>
> that make Nova version agnostic and allow to work with both glance apis. The<br>
> idea of the solution is to determine the current api version in the<br>
> beginning and make appropriate requests after.<br>
> (<a href="https://review.openstack.org/#/c/228578/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/228578/</a>,<br>
> <a href="https://review.openstack.org/#/c/238309/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/238309/</a>,<br>
> <a href="https://review.openstack.org/#/c/259097/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/259097/</a>)<br>
><br>
> Indeed, it requires some additional (and painful) work, but now all tempest<br>
> tests pass in Jenkins.<br>
><br>
> Note: this thread is not about xenplugin, there is another topic, called<br>
> 'Xenplugin + Glance_v2 = Hate'<br>
><br>
> Here the main issues we faced and how we've solved them:<br>
><br>
> 1. "changes-since" filter for image-list is not supported in v2 api. Steve<br>
> Lewis made a great job and implemented a set of filters with comparison<br>
> operators <a href="https://review.openstack.org/#/c/197388/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/197388/</a>. Filtering by<br>
> 'changes-since' is completely similar to 'gte:updated_at'.<br>
><br>
> 2. Filtering by custom properties must have prefix 'property-'. In v2 it's<br>
> not required.<br>
><br>
> 3. V2 states that all custom properties must be image attributes, but Nova<br>
> assumes that they are included in 'properties' dictionary. It's fixed with<br>
> glanceclient's method 'is_base_property(prop_name)', that returns False in<br>
> case of custom property.<br>
><br>
> 4. is_public=True/False is visibility="public"/"private" respectively.<br>
><br>
> 5. Deleting custom image properties in Nova is performed with 'purge_props'<br>
> flag. If it's set to True, then all prop names, that are not included in<br>
> updated data, will be removed. In case of v2 we have to explicitly specify<br>
> prop names in the list param 'remove_props'. To implement this behaviour, if<br>
> 'purge_props' is set, we make additional 'get' request to determine the<br>
> existing properties and put in 'remove_prop' list only those, that are not<br>
> in updated_data.<br>
><br>
> 6. My favourite:<br>
> There is an ability to activate an empty image by just providing 'size = 0':<br>
> <a href="https://review.openstack.org/#/c/9715/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/9715/</a>, in this case image will be a<br>
> collection of metadata. Glance v2 doesn't support this "feature" and that's<br>
> why we have to implement a very dirty workaround:<br>
>     * v2 requires, that disk_format and container-format must be set before<br>
> the activation. if these params are not provided to 'create' method then we<br>
> hardcode it to 'qcow2' and 'bare'.<br>
>     * we call 'upload' method with empty data (data = '') to activate image.<br>
> Me (and the rest glance team) think that this image activation with<br>
> zero-size is inconsistent and we won't implement it in v2. So, I'm going to<br>
> ask if Nova really needs this feature and maybe it's possible to make it<br>
> work without it.<br>
<br>
</div></div>Nova uses this functionality when it creates snapshots of volume<br>
backed instances, that is, instances that only have Cinder volumes<br>
attached and do not have an ephemeral disk.<br>
In this case Nova API creates Cinder snapshots for the Cinder volumes<br>
and builds the block_device_mapping property with block devices that<br>
reference the Cinder snapshots.  Nova activates this image with size=0<br>
because this image does not have a disk and simply refers to the<br>
collection of Cinder snapshots that collectively comprise the binary<br>
image.  Callers of Glance outside of Nova may also use the APIs to<br>
create "block device mapping" images as well that contain references<br>
to Cinder volumes to attach, blank volumes to create, snapshots to<br>
create volumes from, etc during the server creation.  Not having the<br>
ability to create these images with V2 is a loss of function.<br>
<br>
The callers could supply 1 byte of junk data, like a space character,<br>
but that would result in a junk image being stored in Glance's default<br>
backing store for the image.  It would also give the impression that a<br>
real disk image exists for the image in a backing store which could be<br>
fetched, which is incorrect.<br>
<br>
If I remember correctly Glance V2 lets you transition an image from<br>
queued to active state with size = 0 if the image is using an external<br>
backing store such as http.  The store is then called to fetch the<br>
size.  Would it be possible to allow Glance to consider images with<br>
size = 0 and the block_device_mapping property to be "externally<br>
sourced" and allow the transition?<br>
<span class=""><br>
<br>
<br>
><br>
> In conclusion, I want to congratulate you with this huge progress and say<br>
> there is a big chance that we can deprecate glance v1 in Mitaka cycle.<br>
><br>
> Hooray!<br>
> And Merry Christmas!<br>
><br>
> --<br>
> Best regards,<br>
> Mikhail Fedosin<br>
><br>
</span>> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>