Open Stack

Hi Huangtianhua,

Bit more general pointers here and I respond to your exact cases inline.

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.

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.

On Fri, May 20, 2016 at 4:36 AM, Huangtianhua <huangtianhua at huawei.com>
wrote:

> 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?
>
>
This is actually good example why the user nor the cloud owner would not
want to have this happening:
a) This needs glance http backend to be enabled, it's not by default and
the state varies between deployments. Poor interoperability.
b) If the http backend is enabled glance will download the image from
fedoraproject.org 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.
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.

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.

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

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.

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.

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.

Best regards,
Erno "jokke_" Kuvaja

--------------------------------
>
> >
> >
> > 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
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160520/3cac8746/attachment.html>