[openstack-dev] [heat] Client checking of server version
zbitter at redhat.com
Wed Jan 6 17:03:06 UTC 2016
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 . It revolves around clients being able to access
>>> older versions of servers (that's a pretty simplistic description; see
>>>  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:
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.
>>> 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('.') for i in
>>> 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.
>> 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
>>>  https://review.openstack.org/#/c/239504/
>>>  https://review.openstack.org/#/c/226157/
>>> OpenStack Development Mailing List (not for usage questions)
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev