[openstack-dev] [Ironic] ENROLL node state is introduced - next steps [ACTION RECOMMENDED]
divius.inside at gmail.com
Mon Jul 20 21:11:34 UTC 2015
We started using API versioning specifically to be able to introduce
breaking changes. If we disallow this, the whole versioning will become
even more pointless.
What concerns you is the one of the downsides of feature hiding that I was
talking about for a long time, and nobody seemed to care. We did the same
thing for AVAILABLE state by the way, which was the reason to fast forward
API versioning without a proper discussion.
I'm also not fond of users opting out from changes we introduce, to be
20 июля 2015 г. 21:30 пользователь "Devananda van der Veen" <
devananda.vdv at gmail.com> написал:
> So, as you know, I think that a breaking change like this is really bad
> for our users, no matter how loudly we declare it or when we do it. Version
> negotiation in the REST API doesn't give us license to do this. I also
> think most users should not need to know the version number at all, should
> be able to expect consistent behavior from their applications when ever
> they upgrade either their server or client, and should be able to *opt in
> to* changes in behavior.
> An alternative to your proposal would be:
> - add optional parameter to node creation REST API that accepts initial
> state [ENROLL || AVAILABLE]
> - default if unspecified remains AVAILABLE for backwards compatibility
> - CLI grows an entirely new command "node-enroll", to enable the new
> - [optional] deprecate the "node-create" command in our client over a few
> release cycles
> Along with the requisite API version bump to indicate the acceptance of
> the new parameter, users will get the following combination of behaviors:
> a) old client + new server: user app still works the same
> b) new client + old server: user app still works the same
> c) new client + new server: user app still works the same
> d) new client + new server + user opts in to new behavior: user app must
> behave differently
> By contrast, your current approach will impact users in case (c) as soon
> as we release a client which defaults to any API version >= 1.11.
> On Thu, Jul 16, 2015 at 4:30 AM Dmitry Tantsur <dtantsur at redhat.com>
>> Hi all!
>> Today we landed a patch  that switches (starting with API version
>> 1.11) node creation API to default to ENROLL node state instead of
>> AVAILABLE. Nothing to worry about right now: we don't default to this
>> API version (yet?) in our clients. But read on to figure out how not to
>> get broken in the future.
>> Nodes in ENROLL state a basically just records in the database. They are
>> not used for scheduling, the only way to make them enter the play is via
>> "manage" provision actions. This means, when you switch to API 1.11 for
>> node creation, your tooling will probably get broken. There are 2 steps
>> to get your tooling prepared for it:
>> 1. Switch to new version right now with fixing whatever breaks.
>> If you're targetting liberty I recommend you start explicitly using 1.11
>> API, e.g. for CLI:
>> $ ironic --ironic-api-version 1.11 node-create ....
>> 2. Even if you're not doing step 1, you can make your code compatible
>> with both pre-1.11 and 1.11 API. Just insert 2 more transitions after
>> creating a node - "manage" and "provide". E.g. for CLI:
>> $ ironic node-set-provision-state UUID manage
>> # wait
>> $ ironic node-set-provision-state UUID provide
>> # wait
>> For Kilo it would simply move node to MANAGEABLE and back to AVAILABLE.
>> Important side note: some people don't realize that ALL provision state
>> transitions are asynchronous. And all of them can fail! Even if "manage"
>> action was seemingly instant and synchronous before 1.11, it was not.
>> Now with 1.11 API in place "manage" action may take substantial time and
>> may fail. Make sure your tooling account for it.
>> Now it's up to the ironic team to decide  whether and when we're
>> bumping ironicclient default API version to something above 1.11.
>>  https://review.openstack.org/#/c/194722/
>>  https://review.openstack.org/#/c/196320/
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev