Open Stack

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.

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


If we have a different answer to (1) then that could change the answers 
to (2) and (3).

cheers,
Zane.