Open Stack

Excerpts from Jay Dobies's message of 2016-01-04 12:53:07 -0800:
> 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.
> 

I strongly disagree with anything that requires every clientn in every
language that wants to operate with older and newer services to have
the same clever knowledge implemented.

Try writing the REST documentation for it:

"If you want to do something with environments, query the template
portion of the API, and if you can use templates newer than 2016-04-18,
then you can use the new environments feature. Do not be confused by this,
it is totally unrelated to the template format you are using."

Sounds like it is time to micro-version Heat's API.