[openstack-dev] [heat] Client checking of server version

Jay Dobies jason.dobies at redhat.com
Wed Jan 6 19:55:37 UTC 2016

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list