Re: [openstack-dev] [Ironic] How to deal with microversions in 3rdparty tools
On 04/07/2015 11:35 PM, Michael Davies wrote: On Tue, Apr 7, 2015 at 10:32 PM, Dmitry Tantsur dtant...@redhat.com mailto:dtant...@redhat.com wrote: 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? I agree with Jim R's suggestion - it's really up to the consumer as to what they want to do. Having said that... I think that any consumer wants to use the latest version of the API that it can support. And so since we're not planning on making any breaking API changes[1], I think any consumer wants to: a) have a concept of the latest API version that it has been coded for b) then, in negotiation with the server, choose a version that suffices: b1) negotiated_version = min(your code's max version, max Ironic server version) and b2) negotiated_version your code's supported version b3) negotiated_version Ironic API's minimum version Is that statement about not planning on making any breaking API changes an intention or a guarantee? The reason I ask is that doc/source/devref/api_microversions.rst contains an explicit mention of making breaking changes: So breaking changes can be added to the API without breaking users who don't specifically ask for it. Chris __ 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
Re: [openstack-dev] [Ironic] How to deal with microversions in 3rdparty tools
On Wed, Apr 8, 2015 at 7:38 AM Chris Friesen chris.frie...@windriver.com wrote: On 04/07/2015 11:35 PM, Michael Davies wrote: I agree with Jim R's suggestion - it's really up to the consumer as to what they want to do. Having said that... I think that any consumer wants to use the latest version of the API that it can support. And so since we're not planning on making any breaking API changes[1], I think any consumer wants to: a) have a concept of the latest API version that it has been coded for b) then, in negotiation with the server, choose a version that suffices: b1) negotiated_version = min(your code's max version, max Ironic server version) and b2) negotiated_version your code's supported version b3) negotiated_version Ironic API's minimum version Is that statement about not planning on making any breaking API changes an intention or a guarantee? The reason I ask is that doc/source/devref/api_microversions.rst contains an explicit mention of making breaking changes: So breaking changes can be added to the API without breaking users who don't specifically ask for it. We will continue to support the same API that we had at the point we introduced microversioning, which can be represented as v1.1, and is inferred when there is no version header in the request. This should be completely compatible with any client built against stable/juno. There was a change introduced during Kilo which may break some clients, were they not to upgrade; that change is only exposed when the requested version is = 1.2. Thus, older clients are not affected (but also do not see new features). In versions 1.3 - 1.6, we made several additions that we believed would not break any client expecting v1.2, but incremented the API microversion to indicate those changes. In this way, a newer client could discover what is supported by a server it connects to. I have no plans to remove support for v1.1 at this time. The language in the spec lays out the approach we should take, were we ever to find the need to remove support for v1.1. While I hope we never need to, describing it was an important part of the process to arrive at how we implemented microversions. -Devananda __ 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-dev] [Ironic] How to deal with microversions in 3rdparty tools
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
Re: [openstack-dev] [Ironic] How to deal with microversions in 3rdparty tools
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. Hope that helps. :) // jim On April 7, 2015 at 6:07:57 AM, Dmitry Tantsur (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
Re: [openstack-dev] [Ironic] How to deal with microversions in 3rdparty tools
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
Re: [openstack-dev] [Ironic] How to deal with microversions in 3rdparty tools
On 04/07/2015 07:25 AM, Dmitry Tantsur wrote: 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. I'm not familiar with discoverd, but if you consume the nova API messages then I don't think you can allow arbitrary microversions since new ones can break backwards compatibility. Could you cap what the user is allowed to specify as the highest supported microversion that was supported by discoverd at the time of the discoverd release? Chris __ 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
Re: [openstack-dev] [Ironic] How to deal with microversions in 3rdparty tools
Hi, In Tempest, there is similar discussion. Now Nova and Ironic have implemented API microversions in Kilo. Nova's microversions are v2.1 - v2.3. Ironic's microversions are v1.1 - v1.6. Now Tempest is testing the lowest microversion on the gate, and Ironic's microversions test patch[1] is on the gerrit. Before merging the patch, I'd like to propose consistent test way for microversions of Nova and Ironic. My suggestion is the test target microversions are: * the lowest microversion * the biggest microversion, but don't use the keyword latest on a header and these microversions tests are operated on different gate jobs. The lowest microversion is already tested on check-tempest-dsvm-full or something, so this proposes just to add the biggest microversion job like check-tempest-dsvm-full-big-microversion. Same as Tempest, I propose to use (in other word, test) both; * The lowest microversion * The biggest microversion without the keyword latest How do you think? Best Regards, Yuiko Takada 2015-04-07 22:02 GMT+09:00 Dmitry Tantsur dtant...@redhat.com: 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
Re: [openstack-dev] [Ironic] How to deal with microversions in 3rdparty tools
On Tue, Apr 7, 2015 at 10:32 PM, Dmitry Tantsur dtant...@redhat.com wrote: 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? I agree with Jim R's suggestion - it's really up to the consumer as to what they want to do. Having said that... I think that any consumer wants to use the latest version of the API that it can support. And so since we're not planning on making any breaking API changes[1], I think any consumer wants to: a) have a concept of the latest API version that it has been coded for b) then, in negotiation with the server, choose a version that suffices: b1) negotiated_version = min(your code's max version, max Ironic server version) and b2) negotiated_version your code's supported version b3) negotiated_version Ironic API's minimum version I think that way you get the best of both worlds - stability, and latest functionality available. Jim R's suggestion of using latest is fine (especially for internal tools that can have a lower uptime) so long as you can deal quickly with any breakage should it occur :) [1] hopefully :) -- Michael Davies mich...@the-davies.net Rackspace Australia __ 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
