Open Stack

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

>> 3) How do we handle existing templates in future?
>>
>> - Again, if we're not replacing it with anything, the -> Deprecated ->
>> Hidden process is sufficient. (In theory "Hidden" should mean you
>> can't create new stacks containing that resource type any more, only
>> continue using existing stacks that contained it. In practice, we
>> didn't actually implement that and it just gets hidden from the
>> documentation. Obviously trying to create a new one using the location
>> field once only the v2 API is available will result in an error.)
>>
>
> My worry is that portable heat templates like the Community App Catalog
> ( http://apps.openstack.org/#tab=heat-templates) would become much more
> complex if we have to produce different resources for Glance V1 and V2
> configurations. If, however, we are able to say that the following
> definitions of image resources are compatible across the two
> configurations, this can be more supportive of a catalog approach and
> improve template portability.

Are any of those templates actually using OS::Glance::Image resources 
though? (I'd check myself but I can't find the source repo - 
openstack/app-catalog appears to contain just the catalog and not any of 
the apps?)

cheers,
Zane.

> Tim
>
>>
>> If we have a different answer to (1) then that could change the
>> answers to (2) and (3).
>>
>> cheers,
>> Zane.
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org
>> <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> 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
>