Excerpts from Zane Bitter's message of 2017-01-10 15:28:04 -0500: > On 10/01/17 14:17, Tim Bell wrote: > > > >> On 10 Jan 2017, at 17:41, Zane Bitter <zbit...@redhat.com > >> <mailto:zbit...@redhat.com>> wrote: > >> > >> On 10/01/17 05:25, Flavio Percoco wrote: > >>> > >>> > >>>> I'd recommend Heat to not use locations as that will require deployers > >>>> to either enable them for everyone or have a dedicate glance-api node > >>>> for Heat. > >>>> ----If not use location, do we have other options for user? What > >>>> should user to do before create a glance image using v2? Download the > >>>> image data? And then pass the image data to glance api? I really don't > >>>> think it's good way. > >>>> > >>> > >>> That *IS* how users create images. There used to be copy-from too (which > >>> may or > >>> may not come back). > >>> > >>> Heat's use case is different and I understand that but as I said in my > >>> other > >>> email, I do not think sticking to v1 is the right approach. I'd rather > >>> move on > >>> with a deprecation path or compatibility layer. > >> > >> "Backwards-compatibility" is a wide-ranging topic, so let's break this > >> down into 3 more specific questions: > >> > >> 1) What is an interface that we could support with the v2 API? > >> > >> - If copy-from is not a thing then it sounds to me like the answer is > >> "none"? We are not ever going to support uploading a multi-GB image > >> file through Heat and from there to Glance. > >> - We could have an Image resource that creates a Glance image from a > >> volume. It's debatable how useful this would be in an orchestration > >> setting (i.e. in most cases this would have to be part of a larger > >> workflow anyway), but there are some conceivable uses I guess. Given > >> that this is completely disjoint from what the current resource type > >> does, we'd make it easier on everyone if we just gave it a new name. > >> > >> 2) How can we avoid breaking existing stacks that use Image resources? > >> > >> - If we're not replacing it with anything, then we can just mark the > >> resource type as first Deprecated, and then Hidden and switch the back > >> end to use the v2 API for things like deleting. As long as nobody > >> attempts to replace the image then the rest of the stack should > >> continue to work fine. > >> > > > > Can we only deprecate the resources using the location function but > > maintain backwards compatibility if the location function is not used? > > location is a required property: > > http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Glance::Image > > The resource type literally does not do anything else but expose a Heat > interface to a feature of Glance that no longer exists in v2. That's > fundamentally why "add v2 support" has been stalled for so long ;) >
I think most of this has been beating around the bush, and the statement above is the heart of the issue. The functionality was restricted and mostly removed from Glance for a reason. Heat users will have to face that reality just like users of other orchestration systems have to. If a cloud has v1.. great.. take a location.. use it. If they have v2.. location explodes. If you want to get content in to that image, well, other systems have to deal with this too. Ansible's os_image will upload a local file to glance for instance. Terraform doesn't even include image support. So the way to go is likely to just make location optional, and start to use v2 when the catalog says to. From there, Heat can probably help make the v2 API better, and perhaps add support to to the Heat API to tell the user where they can upload blobs of data for Heat to then feed into Glance. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
