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 ;)
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-requ...@lists.openstack.org
<mailto:openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
