[openstack-dev] [Ironic] How to deal with microversions in 3rdparty tools
dtantsur at redhat.com
Tue Apr 7 13:25:23 UTC 2015
On 04/07/2015 03:15 PM, Jim Rollenhagen wrote:
> I’m not sure that recommending one or the other is best.
> We should lay out the options (as you just did) and let folks decide
> what works best for them. For things like discoverd, where you have
> many users, perhaps you should allow the user to pass a version (for
> example, option 2 depends on the user running an Ironic version
> that has a 1.6 at all — they could be at 1.4). For things like the
> dashboard my team runs internally, we’ll be passing “latest” to the
> API (we don’t use the client). We know we can move fast, and our
> dashboard being broken for a short time following a deploy isn’t
> the end of the world.
Allowing a user to set microversions looks to me kind of misuse of them.
E.g. a user setting 1.8 does not mean discoverd will start supporting it
actually. And I can't get any guarantees about 1.4 as well - I never
tested it. So it's really about whether to hard code or not.
Also Juno case is a bit exceptional: Ironic Juno will ignore a header no
matter if it supports the version. So putting 1.6 might be a safe option.
In the future though it leads to a nasty compromise: sacrifice either
compatibility with old versions or new features. That's what bothered me
a bit with the whole microversioning as we implemented it.
Anyway I think we should have a document laying out stuff like that.
> Hope that helps. :)
> // jim
> On April 7, 2015 at 6:07:57 AM, Dmitry Tantsur (dtantsur at redhat.com
> <mailto:dtantsur at redhat.com>) wrote:
>> Hi again, hope you're not tired of this topic :D
>> I'm seeking for advice on what to do with microversions in discoverd.
>> Basically I have the following options:
>> 1. Do nothing. Get whatever behavior I can get from installed Ironic and
>> Ironic client. Though unlikely, may get broken by future changes.
>> 2. Demand version = 1.6. Looks like it keeps compatibility with old
>> clients and servers, not sure what downsides are here.
>> What are we going to recommend now as upstream?
>> 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