[openstack-dev] [Heat][Glance] Can't migrate to glance v2 completely

Nikhil Komawar nik.komawar at gmail.com
Wed May 11 14:02:41 UTC 2016


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

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

[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





More information about the OpenStack-dev mailing list