[openstack-dev] [heat] Client checking of server version
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 . It revolves around clients being able to access
>>> versions of servers (that's a pretty simplistic description; see 
>>> for the
>>> Before the holiday, Steve Hardy and I were talking about the
>>> involved. In my case, there's no good way to differentiate an older
>>> from a legitimate error.
>>> Since the API isn't versioned to the extent that we can leverage that
>>> 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('.') for i in
>>> 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
>>> 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
>> 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
>> 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
>> -e is short for "--environment-file", but we could introduce a new
>> 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
>> pass the files unmodified for resolution inside heat (by using the new
>> 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.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev