Open Stack

On Tue, Jan 10, 2017 at 9:28 PM, Zane Bitter <zbitter at redhat.com> wrote:
> On 10/01/17 14:17, Tim Bell wrote:
>>
>>
>>> On 10 Jan 2017, at 17:41, Zane Bitter <zbitter at redhat.com
>>> <mailto:zbitter at 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 ;)

Throwing stuff against the wall, but could we solve the issue in
heatclient? If we change it to handle the location property, upload
the image from the client, and pass the id to Heat, it could be
somewhat transparent to the user. We'd need to do it in Horizon
though. For the heatclient as a library it's not perfect, but it may
be good enough.

-- 
Thomas