[openstack-dev] The Nova API in Kilo and Beyond
Neil.Jerram at metaswitch.com
Fri Jun 5 14:56:33 UTC 2015
On 05/06/15 12:32, Sean Dague wrote:
This is really informative and useful, thanks.
A few comments / questions, with bits of your text in quotes:
"Even figuring out what a cloud could do was pretty terrible. You could
approximate it by listing the extensions of the API, then having a bunch
of logic in your code to realize which extensions turned on or off
certain features, or added new data to payloads."
I guess that's why the GNU autoconf/configure system has always advised
testing for particular wanted features, instead of looking at versions
and then relying on carnal knowledge to know what those versions imply.
Is that feature-testing-based approach impractical for OpenStack?
"Then she runs her code at against another cloud, which runs a version
of Nova that predates this change. She's now effectively gone back in
time. Her code now returns thousands of records instead of 1, and she's
terribly confused why. She also has no way to figure out if random cloud
Z is going to support this feature or not. So the only safe thing to do
is implement the filtering client side instead, which means the server
side filtering actually gained her very little. It's not something she
can ever determine will work ahead of time. It's an API that is
untrustworthy, so it's something that's best avoided."
Except that she still has to do all this anyway - i.e. write the
client-side filtering, and figure out when to use it instead of
server-side - even if there was an API version change accompanying the
filtering feature. Doesn't she?
The difference is just between making the switch based on a version
number, and making it based on detected feature support.
"If you want features in the 2.3 microversion, ..."
I especially appreciate this part, as I've been seeing all the chat
about microversions go past, and not really understanding it.
FWIW, though - and maybe this is just me - when I hear "microversion",
I'm thinking of the "Z" in an "X.Y.Z" version number. (With X = major
and Y = minor.) So it's counterintuitive for me that "2.3" is a
microversion; it just sounds like a perfectly normal major/minor version
number. Are 2.0 and 2.1 microversions too?
But this is just bikeshedding really, so feel free to ignore...
"without building a giant autoconf-like system"
Aha, so you probably did consider that option, then. :-)
More information about the OpenStack-dev