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: [email protected]?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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
