<div dir="ltr"><div><div><div>Hi Huangtianhua,<br><br></div>Bit more general pointers here and I respond to your exact cases inline.<br><br></div>OpenStack community has made really clear that we must not expose backend configuration details of the services to users and we must not rely users knowing any of those details to operate in the cloud. The locations settings are exact opposite from this. To set the locations in a manner that glance can access the image when the user tries to use it excepts the user to provide correct, backend specific location of the image to Glance. This causes very much poor user experience from the beginning but definitely so when the user tries to transfer those processes between clouds that are configured differently.<br><br></div>Also utilizing external locations for enabled backends (locations that are not controlled by Glance) we give away the immutability promise right away. We also break the image in the cloud in the case the image is not anymore available in that external backend preventing spinning up new VMs from that image, migrating those VMs to other hosts and IIUC spinning up even VMs from the snapshots based on that base image. All these things just leading horrible results for any users not understanding the internals how our clouds operates and consequences of such decisions.<br><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 20, 2016 at 4:36 AM, Huangtianhua <span dir="ltr"><<a href="mailto:huangtianhua@huawei.com" target="_blank">huangtianhua@huawei.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Thanks very much and sorry to reply so late. Comments inline.<br>
<br>
-----邮件原件-----<br>
发件人: Nikhil Komawar [mailto:<a href="mailto:nik.komawar@gmail.com">nik.komawar@gmail.com</a>]<br>
发送时间: 2016年5月11日 22:03<br>
收件人: OpenStack Development Mailing List (not for usage questions)<br>
抄送: Huangtianhua<br>
主题: Re: [openstack-dev] [Heat][Glance] Can't migrate to glance v2 completely<br>
<span class=""><br>
<br>
Thanks for your email. Comments inline.<br>
<br>
On 5/11/16 3:06 AM, Huangtianhua wrote:<br>
><br></span></div><span class=""></span><span class="">> Hi glance-team:<br></span><div><span class="">
><br></span></div><div><span class="">
> 1.<br>
> glance v1 supports '--location' in Api image-create, we support<br>
> 'location' in heat for glance image resource,<br>
><br>
><br>
> and we don't support '--file' to use local files for upload, as the<br>
> caller has no control over local files on the<br>
><br>
><br>
> server running heat-engine or there are some security risk.<br>
><br>
<br>
We had a session during the summit to discuss the deprecation path. You are right currently v2 does not have the location support. Also, please be mindful that location concept in v2 (you mention above) is a bit different from that in v1.<br>
<br>
It's unfortunate that public facing services have exposed v1 as v1 was designed to be the internal only (service) API for usage by Infrastructure services. v2 on the other had has been designed to be used by end users and PaaS services.<br>
<br>
Ideally, a location should never be set by the end user as the location mechanism used by Glance needs to be opaque to the end user (they can not be sure the scheme in which the location needs to be set to be acceptable to Glance). location logic was introduced to help admin<br>
(operators) set a custom location on an image to help speed the boot times. Hence, it's a service API in a way (unless you run a very small trusted cloud). (In cast of heat, the scale and type of cloud would be quite different.)<br>
<br>
</span>------------------------------<br>
In fact, I don't understand why the end user can't set 'location', the 'location' to me is the url where the data for the image already resides, and let's consider a simple user case with heat template:<br>
<br>
heat_template_version: 2013-05-23<br>
resources:<br>
  fedora_image:<br>
    type: OS::Glance::Image<br>
    properties:<br>
      disk_format: qcow2<br>
      container_format: bare<br>
      location: <a href="http://download.fedoraproject.org/pub/fedora/linux/releases/21/Cloud/Images/x86_64/Fedora-Cloud-Base-20141203-21.x86_64.qcow2" rel="noreferrer" target="_blank">http://download.fedoraproject.org/pub/fedora/linux/releases/21/Cloud/Images/x86_64/Fedora-Cloud-Base-20141203-21.x86_64.qcow2</a><br>
  my_server:<br>
    type: OS::Nova::Server<br>
    properties:<br>
      # other properties<br>
      image: {get_resources: fedora_image}<br>
<br>
as above user want to use a fedora release image to create a nova server. So if user can't set the image 'location', how to use the image, is there any other way in glance v2?<br>
<br></div></blockquote><div><br>This is actually good example why the user nor the cloud owner would not want to have this happening:<br></div><div>a) This needs glance http backend to be enabled, it's not by default and the state varies between deployments. Poor interoperability.<br></div><div>b) If the http backend is enabled glance will download the image from <a href="http://fedoraproject.org">fedoraproject.org</a> every time that image is requested (assuming glance image cache is not enabled or the image is not in the cache of serving node) causing lots of external network traffic and most of the cases greatly slowing the boot process down.<br></div><div>c) Lets assume that location URI is directing some smaller and perhaps less stable direction than fedoraproject. The user uses that VM happily, takes a snapshot of the baseline for his/her future uses. Meanwhile the Image creator has uploaded new version of that image and removes the old one to save some space. Now our user tries to spin up that snapshot, the image does not exist in the URI anymore, Glance cannot fetch it and provide to Nova as base image for that snapshot, boot fails and all the work that user did has been lost.<br></div><div><br>All of the reasons above increases poor user experience greatly and should be avoided. Specially as all of those are something where the user would need deep understanding of the underlying operations and will blame OpenStack or the cloud operator for this horrible user experience.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
Consider another user case of using custom image store in swift, user store the custom image data in swift already. The schema likes:<br>
swift+<a href="http://tenant/account:key@auth_url/container/obj" rel="noreferrer" target="_blank">http://tenant/account:key@auth_url/container/obj</a><br>
it is really complex, but if this location only expose to admin(operator), they need to get the key(password) of all the end-users? Is it safe?<br>
<br></div></blockquote><div>This exact use case is something we're trying to facilitate with the Image Import work that is currently ongoing. Although this is something that Heat for example should avoid hard coding in anywhere as Swift is not required component on all models of OpenStack clouds.<br><br></div><div>Also if used in location the password would need to be stored (and updated, which is still a problem) in Glance so it would be able to access the image in future exposing the password for the admins anyways.<br></div><div><br></div><div>This possible lack of Swift also complicates the Image Import work we are currently doing as we can't count that workflow being possible to import those images from Swift to configured Glance backend.<br><br></div><div>The only reliable way to create Glance images for consumption in general manner is to make sure that we use the normal workflows (currently uploading the image to Glance and in future the supported manners of Image Import) and let Glance and Glance only to deal with it's backends.<br><br></div><div>Best regards,<br></div><div>Erno "jokke_" Kuvaja<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
--------------------------------<br>
<span class=""><br>
><br>
><br>
> 2.<br>
> glance v1 is deprecated, I want to migrate to use glance v2 in heat,<br>
> so for glance image resource, I think<br>
><br>
><br>
> we need to call two Apis when image creation: first, image-create,<br>
> then add-location, but for glance v2, 'location'<br>
> apis(add-location,<br>
><br>
><br>
> remove-location, replace-location) are unavailable by default, due the<br>
> config option 'show_multiple_locations' which<br>
><br>
><br>
> default value is false, the function **location** is disabled by<br>
> default. So if we migrate to glance v2, then user can't<br>
><br>
><br>
> create glance image resource by default, it’s unacceptable. I wonder<br>
> if we can set the config option to true to<br>
><br>
><br>
> compatible with glance v1? Or what’s your suggestion to migrate to<br>
> glance v2 completely?<br>
><br>
<br>
(as I mentioned above) The location APIs have been designed to be used by admins and are not supposed to be exposed to end user (or proxy to end user calls). It is a security risk when enabling that config option and unless the deployment is absolutely sure (like a private/trusted glance installation), they shouldn't enable it. Also, it's not the upload/import call that will be included as a part of interoperability [1].  I think a use case to support "copy-from" a location is worthy to be supported in v2 -- where a user specifies a location and the data can be pulled in by glance from that http url. It has been asked for by a few other user and we are strongly considering that case. I will be meeting defcore folks to identify the implications of the same (to confirm if we should or not).<br>
<br>
As far as other alternatives are concerned, I will need to take a closer look at all the possible ways you are letting users create image to better consult you. But please (please) DO NOT expose locations (read or write).<br>
<br>
</span>----------------------<br>
So your suggestion is to wait the function 'import'?<br>
As above user cases, the problem for me is how to migrate to glance v2 completely, is there any other way that I can translate the 'location' to?<br>
<br>
_____________<br>
[1]<br>
<a href="http://specs.openstack.org/openstack/glance-specs/specs/mitaka/approved/image-import/image-import-refactor.html" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/glance-specs/specs/mitaka/approved/image-import/image-import-refactor.html</a><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> ______________________________________________________________________<br>
> ____ OpenStack Development Mailing List (not for usage questions)<br>
<div class="HOEnZb"><div class="h5">> Unsubscribe:<br>
> <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>
Thanks again for your business and I will be happy to assist further as required.<br>
<br>
--<br>
<br>
Thanks,<br>
Nikhil<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>
</div></div></div></blockquote></div><br></div></div></div></div></div></div>