Open Stack

On 06/01/16 08:53, 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.
>>
>> 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.

Ah, OK, so we are silently ignoring invalid data in the request here:

http://git.openstack.org/cgit/openstack/heat/tree/heat/api/openstack/v1/stacks.py#n359

That seems like a bug to me. We could fix that and backport it to at 
least a couple of releases. It would mean that the client would still be 
broken on any older release that didn't have the patch though.

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

Agree.

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