On 01/06/2016 12:05 PM, Zane Bitter wrote:
On 05/01/16 16:37, Steven Hardy wrote:
On Mon, Jan 04, 2016 at 03:53:07PM -0500, Jay Dobies wrote:
I ran into an issue in a review about moving environment resolution from
client to server [1]. It revolves around clients being able to access
older
versions of servers (that's a pretty simplistic description; see [2]
for the
spec).
Before the holiday, Steve Hardy and I were talking about the
complications
involved. In my case, there's no good way to differentiate an older
server
from a legitimate error.
Since the API isn't versioned to the extent that we can leverage that
value,
I was looking into using the template versions call. Something along the
lines of:
supported_versions = hc.template_versions.list()
version_nums = [i.to_dict()['version'].split('.')[1] for i in
supported_versions]
mitaka_or_newer = [i for i in version_nums if i >= '2016-04-08']
Yes, I'm planning on cleaning that up before submitting it :)
What I'm wondering is if I should make this into some sort of
generalized
utility method in the client, under the assumption that we'll need
this sort
of check in the future for the same backward compatibility requirements.
So a few questions:
1. Does anyone strongly disagree to checking supported template
versions as
a way of determining the specifics of the server API.
Ok, so some valid concerns have been raised over deriving things using
the
HOT version (although I do still wonder if the environment itself
should be
versioned, just like the templates, then we could rev the environment
verion and say it supports a list, vs changing anything in the API, but
that's probably a separate discussion).
Taking a step back for a moment, the original discussion was around
providing transparent access to the new interface via heatclient, but
that
isn't actually a hard requirement - the old interface works fine for many
users, so we could just introduce a new interface (which would eventually
become the default, after all non-EOL heat versions released support the
new API argument):
Currently we do:
heat stack-create foo -f foo.yaml -e a.yaml -e b.yaml
And this implies some client-side resolution of the multiple -e
arguments.
-e is short for "--environment-file", but we could introduce a new
format,
e.g "-E", short for "--environment-files":
heat stack-create foo -f foo.yaml -E a.yaml -E b.yaml
This option would work the same way as the current interface, but it
would
pass the files unmodified for resolution inside heat (by using the new
API
format), and as it's opt-in, it's leaving all the current heatclient
interfaces alone without any internal fallback logic?
That would certainly work, but it sounds like a usability/support
nightmare :(
Is there a reason we wouldn't consider bumping the API version to 1.1
for this? We'll have to figure out how to do it some time.
I started to look into the Nova specs on how they handle micro versions.
I have a few other things on my plate I want to finish up this week, but
I should be able to take a stab at a POC for it.
cheers,
Zane.
__________________________________________________________________________
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
