Open Stack

Thanks very much and sorry to reply so late. Comments inline.

-----邮件原件-----
发件人: Nikhil Komawar [mailto:nik.komawar at gmail.com] 
发送时间: 2016年5月11日 22:03
收件人: OpenStack Development Mailing List (not for usage questions)
抄送: Huangtianhua
主题: Re: [openstack-dev] [Heat][Glance] Can't migrate to glance v2 completely


Thanks for your email. Comments inline.

On 5/11/16 3:06 AM, Huangtianhua wrote:
>
>
>
>
>
>
>
>
> Hi glance-team:
>
>
>  
>
>
>
> 1.   
> glance v1 supports '--location' in Api image-create, we support 
> 'location' in heat for glance image resource,
>
>
> and we don't support '--file' to use local files for upload, as the 
> caller has no control over local files on the
>
>
> server running heat-engine or there are some security risk.
>

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.

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.

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
(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.)

------------------------------
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:
  
heat_template_version: 2013-05-23
resources:
  fedora_image:
    type: OS::Glance::Image
    properties:
      disk_format: qcow2
      container_format: bare
      location: http://download.fedoraproject.org/pub/fedora/linux/releases/21/Cloud/Images/x86_64/Fedora-Cloud-Base-20141203-21.x86_64.qcow2
  my_server:
    type: OS::Nova::Server
    properties:
      # other properties
      image: {get_resources: fedora_image}
      
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?

Consider another user case of using custom image store in swift, user store the custom image data in swift already. The schema likes: 
swift+http://tenant/account:key@auth_url/container/obj
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?

--------------------------------

>
>
> 2.   
> glance v1 is deprecated, I want to migrate to use glance v2 in heat, 
> so for glance image resource, I think
>
>
> we need to call two Apis when image creation: first, image-create, 
> then add-location, but for glance v2, 'location'
> apis(add-location,
>
>
> remove-location, replace-location) are unavailable by default, due the 
> config option 'show_multiple_locations' which
>
>
> default value is false, the function **location** is disabled by 
> default. So if we migrate to glance v2, then user can't
>
>
> create glance image resource by default, it’s unacceptable. I wonder 
> if we can set the config option to true to
>
>
> compatible with glance v1? Or what’s your suggestion to migrate to 
> glance v2 completely?
>

(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).

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).

----------------------
So your suggestion is to wait the function 'import'? 
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?  

_____________
[1]
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/approved/image-import/image-import-refactor.html
>
>
>  
>
>
>
>
>
>
>
>
> ______________________________________________________________________
> ____ OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>

Thanks again for your business and I will be happy to assist further as required.

-- 

Thanks,
Nikhil