Open Stack

On 4 August 2015 at 12:20, Jim Rollenhagen <jim at jimrollenhagen.com> wrote:

> On Mon, Jul 27, 2015 at 01:35:25PM -0700, Jim Rollenhagen wrote:
> >
> > Now we've landed a patch[0] with a new version (1.11) that is not
> > backward compatible. It causes newly added Node objects to begin life in
> > the ENROLL state, rather than AVAILABLE. This is a good thing, and
> > people should want this! However, it is a breaking change. Automation
> > that adds nodes to Ironic will need to do different things after the
> > node-create call.
> >
> > Our API versioning scheme makes this opt-in (by specifying the API
> > version). However, some folks have a problem with releasing this change
> > as-is. The logic is that we might release a client that defaults to 1.11
> > or higher, or the user may request 1.12 later to get a new feature, thus
> > breaking their application that enrolls nodes.
>
> So after much deliberation, we took an informal vote in IRC this morning
> between 5 out of our 9 cores.
>
> The question was: "should we do a 1.12 api version that allows the user
> to pick begining provision state in (AVAILABLE, ENROLL), defaulting to
> AVAILABLE?"
>
> The results were 3 for no, 2 for yes. So that's the plan.
>
> Other Ironic cores (Haomeng, Yuriy, Ramesh, Ruby): please chime in if
> you have opinions on this. :)
>
> Otherwise we'll be getting to work on releasing a server as-is in the
> next few days.
>
> // jim
>
>
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! :)

--ruby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150810/a12042a4/attachment.html>