Open Stack

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