Open Stack

>> 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.
>
> Hmmm, it's true that you'll likely just get a 400 error, but I'd hope
> that the error message is at least somewhat unique.

Unfortunately, it's not, but I don't think it's due to a Heat problem so 
much as just the nature of the issue. Here's what's happening.

New Client: doesn't do client-side environment resolution before sending 
it to the server.

Old Server: expects the environment to be fully populated and ignores 
the environment file(s) in the files dict.

The result is the server spits back an error saying that, in my 
scenario, there is no type mapping for jdob::Resource1.

The problem is, I get the exact same result for New Client + New Server 
+ incomplete environment files.

The reason I was looking for some sort of version checking is to avoid 
having logic that just says "Maybe it's because it's an old server, 
lemme resolve the environments and send the request again." It feels 
really wrong to trigger two create requests when it's the templates 
themselves that are wrong.

>> Since the API isn't versioned to the extent that we can leverage that
>
> I mean... it totally is but so far we've chosen not to bump that
> version. And we mostly got away with it because we were only adding
> functionality. So far.
>
>> 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.
>
> Yes.
>
> Template versions are supposed to be pluggable, and are explicitly under
> control of the operator. We shouldn't be systematically inferring
> anything about the server version based on this; in general there's no
> causal relationship.
>
>> 2. Does anything like this already exist that I can use?
>
> Not really; there's the "heat build-info" command, but that is also
> explicitly under the control of the operator (and is empty by default).
>
>> 3. If not, any suggestions on where I should put it? I see a
>> heat.common.utils module but I'm not sure if there is a convention
>> against that module (or common in general) making live server calls.
>>
>> Thanks :D
>>
>>
>> [1] https://review.openstack.org/#/c/239504/
>> [2] https://review.openstack.org/#/c/226157/
>>
>> __________________________________________________________________________
>>
>> 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
>
>
> __________________________________________________________________________
> 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
>