Open Stack

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":

I agree with Zane, this looks like a usability (and backwards compat) 
nightmare.

Not only do you have to get over everyone's muscle memory of typing `-e` 
(I've got it bad) but also all the scripts folks have that use heatclient.

Then there's the docs between "If ... blah blah ... then use -E, 
otherwise use -e" will be a pretty fat stumbling block for folks that 
use different deploys of OpenStack (say, a Juno prod cloud and a Kilo 
staging cloud) if they want to use heat templates on both.

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

-- 
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.