Open Stack

On 01/05/2016 04:37 PM, 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?

+1

My only concern is that the default isn't to exercise the "preferred" 
approach.

However, perhaps I'm viewing things wrong with that as being preferred 
instead of just an alternate for non-heatclient. IIRC, the code is 
largely the same, just being called from two separate places (client v. 
server), so it's not an issue of duplication or the actual logic growing 
stale. And it shouldn't really be an issue of the server-side path 
accidentally breaking since there is CI around it. So maybe my concerns 
are overblown.

It does feel weird to have to document something like that, trying to 
describe the differences between -e and -E, but I suppose if we mark -e 
as deprecated it should be understandable enough.

This also has the benefit of letting this code land without having to do 
a major implementation of micro-versions, so that's a plus :)


> Steve
>
> __________________________________________________________________________
> 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
>