[openstack-dev] [ironic] Re: New API for node create, specifying initial provision state

Ruby Loo rlooyahoo at gmail.com
Tue Aug 18 19:11:33 UTC 2015


Apologies, forgot to add [ironic] to the subject.

On 18 August 2015 at 13:27, Ruby Loo <rlooyahoo at gmail.com> wrote:

> Hi,
>
> I want to start a different thread on this topic because I don't think
> this is about whether/how to do API microversions. Rather, given that we
> are going to support microversioning, how to deal with the non-backward
> compatible change in 1.11 with the ENROLL state (instead of AVAILABLE)
> being the provision state that a node is in, after being created/registered
> in ironic.
>
> (This was from 'Let's talk about API versions,
> http://lists.openstack.org/pipermail/openstack-dev/2015-August/072287.html
> .)
>
> I want to think about this before replying but others are more than
> welcome to reply first so that I may not feel the need to reply :-)
>
> --ruby
> maybe chop off this and above when replying :-)
>
> On 17 August 2015 at 20:20, Robert Collins <robertc at robertcollins.net>
> wrote:
>
>> On 11 August 2015 at 06:13, Ruby Loo <rlooyahoo at gmail.com> wrote:
>> > Hi, sorry for the delay. I vote no. I understand the rationale of
>> trying to
>> > do things so that we don't break our users but that's what the
>> versioning is
>> > meant for and more importantly -- I think adding the ENROLL state is
>> fairly
>> > important wrt the lifecycle of a node. I don't particularly want to hide
>> > that and/or let folks opt out of it in the long term.
>> >
>> > From a reviewer point-of-view, my concern is me trying to remember all
>> the
>> > possible permutations/states etc that are possible to make sure that new
>> > code doesn't break existing behavior. I haven't thought out whether
>> adding
>> > this new API would make that worse or not, but then, I don't really
>> want to
>> > have to think about it. So KISS as much as we can! :)
>>
>> I'm a little surprised by this, to be honest.
>>
>> Here's why: allowing the initial state to be chosen from
>> ENROLL/AVAILABLE from the latest version of the API is precisely as
>> complex as allowing two versions of the API {old, new} where old
>> creates nodes in  AVAILABLE and new creates nodes in ENROLL. The only
>> difference I can see is that eventually someday if {old} stops being
>> supported, then and only then we can go through the code and clean
>> things up.
>>
>> It seems to me that the costs to us of supporting graceful transitions
>> for users here are:
>>
>> 1) A new version NEWVER of the API that supports node state being one
>> of {not supplied, AVAILABLE, ENROLL}, on creation, defaulting to
>> AVAILABLE when not supplied.
>> 2) Supporting the initial state of AVAILABLE indefinitely rather than
>> just until we *delete* version 1.10.
>> 3) CD deployments that had rolled forward to 1.11 will need to add the
>> state parameter to their scripts to move forward to NEWVER.
>> 4) Don't default the client to the veresions between 1.10 and NEWVER
>> versions at any point.
>>
>> That seems like a very small price to pay on our side, and the
>> benefits for users are that they can opt into the new functionality
>> when they are ready.
>>
>> -Rob
>>
>> --
>> Robert Collins <rbtcollins at hp.com>
>> Distinguished Technologist
>> HP Converged Cloud
>>
>> __________________________________________________________________________
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150818/331c189f/attachment.html>


More information about the OpenStack-dev mailing list