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 (dtant...@redhat.com
<mailto:dtant...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
