To be honest, I'm tired of repeating the same arguments again and
again... I personally would like to get something cool done, rather than
discussing how to work around our new state machine again and again.
Now to some trolling: please include a way to users to opt-out from
NOSTATE -> AVAILABLE renaming.
On 08/18/2015 09:11 PM, Ruby Loo wrote:
Apologies, forgot to add [ironic] to the subject.
On 18 August 2015 at 13:27, Ruby Loo <rlooya...@gmail.com
<mailto:rlooya...@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
<robe...@robertcollins.net <mailto:robe...@robertcollins.net>> wrote:
On 11 August 2015 at 06:13, Ruby Loo <rlooya...@gmail.com
<mailto:rlooya...@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.
-1, it's a breaking change again. And it does not make any sense to me.
2) Supporting the initial state of AVAILABLE indefinitely rather
than
just until we *delete* version 1.10.
We don't delete any versions. This would be a terrible (backward
incompatible) change, breaking the whole idea of versioning.
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.
That's what versioning is for, so we're fine, nothing needs to be done.
-Rob
--
Robert Collins <rbtcoll...@hp.com <mailto:rbtcoll...@hp.com>>
Distinguished Technologist
HP Converged Cloud
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://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
