Open Stack

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.

cheers,
Zane.