17:02:09 <devananda> #startmeeting ironic
17:02:10 <openstack> Meeting started Mon Dec  1 17:02:09 2014 UTC and is due to finish in 60 minutes.  The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:13 <openstack> The meeting name has been set to 'ironic'
17:02:17 <devananda> #chair NobodyCam
17:02:19 <openstack> Current chairs: NobodyCam devananda
17:02:23 <devananda> #topic announcements
17:02:37 <devananda> as usual, our agenda is here: https://wiki.openstack.org/wiki/Meetings/Ironic
17:02:46 <devananda> however, not as usual, we're at a new place and time
17:03:03 <devananda> and we're alternating -- so next week will *not* be at this time
17:03:14 <Nisha> devananda, thanks for the new times. It works for us
17:03:44 <devananda> next week will be at 0500 UTC tuesday, which translates to 11pm PST, for those who think in US time zones
17:03:53 <devananda> Nisha: you're welcome
17:03:53 <NobodyCam> :)
17:04:07 <Nisha> :)
17:04:16 <devananda> that's the only announcement from me. NobodyCam  ?
17:04:36 <ChuckC> 0500 UTC == 2100 PST
17:04:39 <lucasagomes> I will be in brazil next week and on, that will me 3am for me. So I won't be able to join the next meeting
17:04:44 <NobodyCam> no announcements here
17:04:53 <naohirot> devananda: I noticed that Neutron team announced surprisingly early deadlines at here
17:05:06 <devananda> ChuckC: urgh. you are correct
17:05:06 <naohirot> https://wiki.openstack.org/wiki/NeutronKiloProjectPlan
17:05:23 <naohirot> devananda: Are we going to announce such that deadlines too?
17:05:32 * ChuckC didn't want to stay up that late ;-)
17:05:36 * dtantsur hopes no
17:05:42 <NobodyCam> wow that is a early deadline
17:06:01 <dtantsur> we won't land anything, if we do :D
17:06:02 <naohirot> NobodyCam: yes
17:06:07 <NobodyCam> like one week
17:06:12 <rloo> my understanding is that we're going with this sched: https://wiki.openstack.org/wiki/Kilo_Release_Schedule
17:06:16 <jroll> wow, let's not do that
17:06:17 <devananda> #info As we are now  alternating weekly times,  next week's meeting is at 0500 UTC Tuesday (or 2100 PST Monday)
17:06:42 <devananda> naohirot: Neutron is doing a very massive refactoring this cycle
17:06:49 <naohirot> rloo: I see
17:06:55 <devananda> naohirot: they are, afaik, the only project doing that. so a separate schedule makes sense for them
17:06:58 <devananda> we are not
17:07:04 <lucasagomes> rloo, +1
17:07:18 <zyluo_> Should there be a specs deadline?
17:07:39 <devananda> rloo pointed to the Kilo release schedule already, and my plan is to follow that for this cycle
17:07:44 <NobodyCam> zyluo_: yes.. we had a deadline last cycle
17:07:44 <devananda> zyluo_: there is. see the link
17:07:46 <naohirot> devananda: so we are following the official schedule at https://wiki.openstack.org/wiki/Kilo_Release_Schedule, right?
17:07:50 <devananda> #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule
17:07:53 <lucasagomes> zyluo_, yes, because of the feature freeze and all
17:07:55 <devananda> yes
17:07:58 <rloo> devananda: maybe an #info and an email out about the spec deadlines?
17:08:03 <naohirot> devananda: Okay
17:08:05 <yuriyz> +1
17:08:16 <devananda> rloo: sure, will do
17:08:24 <devananda> #topic subteam status
17:08:28 <rloo> devananda: thx
17:08:49 <NobodyCam> I like the new status format .... thank you all
17:08:51 <devananda> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:09:10 <devananda> giving folks a minute or two to review the status on the whiteboard
17:09:24 <devananda> if you have questions or comments, please raise them
17:09:24 <jroll> oops
17:09:25 <naohirot> NobodyCam: I added iRMC status :-)
17:09:28 * jroll forgot to update IPA status
17:09:48 <jroll> updated
17:10:23 * zyluo_ just saw featureproposalfreeze
17:11:06 <NobodyCam> naohirot: awesome thank you :)
17:11:27 <naohirot> NobodyCam: wc
17:12:11 <devananda> Nisha: feedback for wanyen - it's great that she is reviewing other specs, but that's not really a driver status report
17:12:45 <Nisha> devananda, ok
17:13:06 <devananda> if there are no questions, let's move on
17:13:10 <NobodyCam> +1
17:13:45 <devananda> #topic changes to the 'maintenance mode' API
17:14:07 <devananda> I filed this bug last week
17:14:09 <devananda> #link https://review.openstack.org/#/c/136934/
17:14:19 <devananda> tldr; there was a LOG line about deprecation
17:14:25 <devananda> in the API service
17:15:05 <devananda> we added a feature recently that allows tracking a maintenance reason, and in so doing, added a second RESTful means to change the status of the maintenance field
17:15:17 <devananda> with no clear way to remove the first method
17:15:33 <devananda> I'd like to suggest that we don't remove it
17:16:19 <NobodyCam> devananda: for backward compat ?
17:16:25 <lucasagomes> I was thinking about having it documented as deprecated for one cycle
17:16:35 <devananda> lucasagomes: documentation != deprecation. users won't know.
17:16:36 <rloo> I don't like having two different ways of doing almost the same thing. But I suppose we already have that/will have that in other situations.
17:16:45 <jroll> I think I'm fine without removing it, I don't see a need to; the only downside of leaving it is that folks can clear maintenance mode without clearing the reason
17:17:04 <lucasagomes> I understand it's hard to programatically say it's deprecated in that case because it's not an endpoint in the API only for that (so you can't use 301 (Permanently Moved) as return code for e.g)
17:17:33 <lucasagomes> right yeah, my concern is once we start adding more stuff to the new endpoint
17:17:39 <rloo> jroll: that isn't good, not clearing the reason
17:17:49 <devananda> there is no means, AFAIK, to indicate to users of our API that PATCH /v1/nodes/<uuid> {op: replace, key: maintenance, value: othervalue} is no longer acceptable
17:17:52 <lucasagomes> like sending notification once the node is put on the maitenance etc, we would need to change in both places
17:17:59 <devananda> so, not clearing the reason is bad -- but also easy to fix
17:18:09 <jroll> rloo: but we could special case *that* part
17:18:23 <rloo> jroll, devananda: yes (we should fix it)
17:18:40 <Nisha> +1
17:18:42 <jroll> lucasagomes: but we should send notifications for PATCH /nodes/uuid as well, nova will see it either way
17:18:54 <jroll> lucasagomes: so I disagree that's a problem
17:18:57 <rloo> is the only reason for not getting rid of it is because we don't know how to deprecate it and we may break someone's usage?
17:19:03 <devananda> lucasagomes: if a user('s existing automation tooling) is using the icehouse,juno PATCH approach, then they have no means to set the maintenance_reason.
17:19:12 <Shrews> devananda: so are you suggesting that the old method could be adjusted to automatically clear the reason
17:19:14 <Shrews> ?
17:19:14 <devananda> lucasagomes: if they're using the new approach, it is clearer for them.
17:19:18 <devananda> Shrews: yes
17:19:26 <lucasagomes> jroll, it's not very user friendly to have 2 endpoints to the same thing
17:19:34 <lucasagomes> not a technical reason
17:19:34 <Shrews> devananda: yeah, that seems like a good compromise
17:19:43 <devananda> Shrews: that solves the "two clients manipulating the same node in different ways leaves dangling data" problem
17:19:45 <rloo> Shrews: and if they set to maintanance on, they can't specify the reason
17:20:04 <lucasagomes> another approach maybe would be to add a custom HTTP header
17:20:08 <lucasagomes> X-deprecated idk
17:20:21 <Shrews> rloo: i don't see that as a problem
17:20:22 <lucasagomes> and in the lib/client we can look at it and give the user a message
17:20:25 <devananda> lucasagomes: I agree that it's not the most user friendly thing to have two APIs to change the same thing. However, breaking the current API without any user-visible warning isn't good either
17:20:31 <rloo> when we have a v2, would we get rid of it then?
17:20:41 <devananda> lucasagomes: there are other clients out there. making a change in ours doesn't inform everyone else of the change
17:20:44 <devananda> rloo: yes :)
17:21:05 <rloo> hmm. ok, i'm fine with this then. On to v2 one day... :-)
17:21:41 <NobodyCam> I can see the value to leaving it.. until we move on to a V2 api
17:21:42 <lucasagomes> aight... yeah it's fine to keep it then. /me runs out of ideas to know how to deprecate that
17:22:16 <devananda> if folks want to discuss futher, let's do that on the bug report / mailing list
17:22:22 <lucasagomes> +1
17:22:34 <Shrews> boo technical debt, but yay helping users
17:22:55 <devananda> #topic discovery is blocked on the state machine
17:23:00 <devananda> dtantsur: hi! I think this is you
17:23:09 <rloo> can we decide now, what to do, or should we always send email to the list for those that can't attend the meeting?
17:23:10 <dtantsur> oh sorry
17:23:25 <devananda> dtantsur: hm, hang on one moment, sorry
17:23:26 <devananda> #undo
17:23:27 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x3ac00d0>
17:23:29 <jroll> I mean, many things are blocked on the state machine...
17:23:56 <devananda> #agreed keep both endpoints for now, plan to drop the old one (if/)when we have a v2 API
17:24:10 <devananda> #topic discovery is blocked on the state machine
17:24:11 <devananda> there :)
17:24:16 <rloo> thx devananda
17:24:35 <rloo> jroll: i'll offer to update the spec
17:24:47 <jroll> rloo: what spec?
17:25:02 <NobodyCam> victor_lowther: just put up a new state machine spec that I have not had a chance to look at BTW
17:25:03 <rloo> jroll: the maintenance spec with the deprecate thingy that I added
17:25:10 <dtantsur> aha. just wanted to get your opinion, if we can short-cut discovery specs, while we're talking about state machine
17:25:12 <devananda> rloo: ++
17:25:15 <jroll> rloo: ok, cool, gopher it
17:25:38 <dtantsur> because discovery only needs 2 new states and does not need e.g. talk about zapping to finish
17:25:48 <rloo> i think we should all try to get the state machine spec approved instead of shortcutting anything else
17:25:50 <victor_lowther> NobodyCam: This rev is tox compliance, speling fixes, and fix the bothced state machine ascii art.
17:26:14 <dtantsur> rloo, discovery spec is ~ready, while state machine is not even close to
17:26:14 <NobodyCam> ahh :)
17:26:18 <devananda> dtantsur: it seemed that the state machine spec discussion had stalled around the init/enroll/discovery process
17:26:18 <victor_lowther> All the substantive issues are still present. :)
17:26:26 <devananda> dtantsur: which makes me hesitant to short cut something in that space
17:26:37 <devananda> dtantsur: also, that discussion is on the agenda today too
17:26:55 <dtantsur> devananda, then maybe postpone this question and proceed to the 2nd?
17:27:07 <devananda> ++
17:27:09 <jroll> I mean, we know there will be discovery states, it's just the transitions that are stalling yes?
17:27:16 <devananda> #info question deferred until later in the agenda
17:27:23 <rloo> dtantsur: you're only blocked on getting code approved for discovery, right?
17:27:29 <lucasagomes> jroll, seems so
17:27:39 <dtantsur> which is: any objections for discovery to be in it's own interface? like IntrospectionInterface?
17:27:47 <jroll> so the discovery spec can just go ahead IMO
17:28:07 <victor_lowther> IMO, discovery should be totally driven by introspection.
17:28:11 <jroll> everyone seems to like IntrospectionInterface, and we'll probably need it... but our driver matrix is getting insane
17:28:34 <victor_lowther> my latest comments to the discovery spec points out that system hw properties are not stable in INIT.
17:28:51 <victor_lowther> jroll: hence composable drivers.
17:28:57 <lucasagomes> yeah... I like the interface as well it gives flexibility to the drivers
17:29:02 <jroll> victor_lowther: I want to try that. people don't think it will work.
17:29:12 <devananda> victor_lowther: or cute names for drivers
17:29:14 <lucasagomes> I believe that people may start compositing their own driver downstream with the interfaces they like
17:29:20 <victor_lowther> jroll: crowbar does it.
17:29:27 * NobodyCam likes cute names
17:29:35 <rloo> so +1 to IntrospectionInterface
17:29:38 <jroll> victor_lowther: right, of course it works in general, I just mean in ironic
17:29:38 <rloo> -1 to cute names ;)
17:29:54 <NobodyCam> ;)
17:30:00 <dtantsur> I think Nisha agreed to IntrospectionInterface too, right?
17:30:02 <victor_lowther> No reason it could not in Ironic
17:30:07 <Nisha> ++
17:30:09 <victor_lowther> v2, that is
17:30:25 <victor_lowther> because there would probably be incompatible API changes.
17:30:33 <devananda> if Ironic "ships with" a set of composed drivers, and instructions on how to compose them differently, should an operator so desire
17:30:44 <devananda> is that enough?
17:30:51 <jroll> victor_lowther: there may be reasons, e.g. drivers sometimes depend on each other
17:31:05 <jroll> I want to figure it out, to be clear
17:31:16 <devananda> I think we'll want to improve the testing around arbitrarily-composable drivers if we go the route of enouraging downstream compositing
17:31:24 <devananda> jroll: exactly my concern
17:31:26 <jroll> devananda: I really want to look into composing them arbitrarily
17:31:27 <jroll> yeah
17:31:27 <victor_lowther> As long as they declare the depencency and the core does the Right Thing with dep info, that is not a problem.
17:31:46 <jroll> yeah
17:31:59 <rloo> we need a spec for composable drivers :-)
17:32:11 <lucasagomes> devananda, it sounds good. Tho we still need to work on some interface dependencies, for e.g pxe deploy also depends on the pxe vendor
17:32:22 <devananda> I don't think we have that today. and so, at least in this cycle, yes, I think we'll see a continued increase in number of entries in the driver namespace
17:32:23 <lucasagomes> without it it doesn't work (because of the pass_deploy_info)
17:32:27 <lucasagomes> but I believe it's a good goal
17:32:28 <devananda> lucasagomes: right
17:32:37 <jroll> indeed
17:32:51 <jroll> enabled_drivers will get interesting, too
17:33:06 <devananda> #info arbitrary driver compositing is a good goal, but not there today (and unlikely for this cycle, given other work)
17:33:11 <dtantsur> are we still arguing about IntrospectionInterface?
17:33:15 * dtantsur is confused
17:33:25 <NobodyCam> jroll: oh thats a good point
17:33:28 <victor_lowther> Not really, but we should be.
17:33:34 <jroll> dtantsur: no, I don't think anyone is saying no to that
17:33:43 <lucasagomes> dtantsur, I think we mostly agreed with the Introspectioninterface
17:33:44 <dtantsur> ack, I'll call it agreed :)
17:33:46 <jroll> NobodyCam: x.x
17:33:53 <rloo> so we're agreed then? +2 for IntrospectionInterfaace?
17:33:53 <lucasagomes> now it's mostly about incrising the matrix to composite a driver
17:33:57 <lucasagomes> but I see it as a diff problem
17:33:58 <devananda> #info adding an IntrospectionInterface increases the number of entries in the driver namespace, but it's a good thing regardless
17:34:08 <dtantsur> Nisha, ^^^
17:34:09 <jroll> lucasagomes: yeah, let's jfdi for now
17:34:12 <devananda> #agreed add new IntrospectionInterface
17:34:19 <NobodyCam> +1 :)
17:34:25 <Nisha> :) +1
17:34:51 <devananda> #topic adding PUT support for API resources
17:34:55 <devananda> vdrok: hi!
17:35:00 <vdrok> devananda, hi
17:35:09 <vdrok> there are couple of questions about adding put to create/update resources
17:35:17 <vdrok> #link https://review.openstack.org/#/c/130228/
17:35:23 <vdrok> change for nodes is here^
17:35:32 <vdrok> should we PUT the whole document or only fields that need to be changed?
17:36:00 <devananda> vdrok: AIUI, PUT by its definition requires one to PUT the whole document
17:36:27 <lucasagomes> indeed, usually it's like GET -> [modify] -> PUT
17:36:37 <lucasagomes> that's why we have PATCH for partial resources updates
17:36:45 <victor_lowther> ya, but I have seen that pretty widely ignored.
17:37:12 <vdrok> ok, then will udpate the change to do that
17:37:21 <vdrok> to reflect the changes i need to add DocImpact and ApiImpact flags to commit messages, is it correct?
17:37:25 <devananda> victor_lowther: how can one express the deletion of an element via PUT without honoring that?
17:37:58 <jroll> just curious, have we already agreed that this is valuable?
17:37:59 <lucasagomes> victor_lowther, well, I mean we should try to suck less then
17:38:11 <devananda> i'm curious -- does anyone feel that we need PUT support for top-level resources (eg nodes, ports) in Ironic?
17:38:24 <victor_lowther> In JSON terms, either by putting the thing with a nil value, or just not handling it well.
17:38:28 <vdrok> jroll, i think i saw that on one of the summit etherpads
17:38:32 <jroll> I don't think we need it, personally
17:38:33 <lucasagomes> the only benefit I see with PUT is that it may be more user friendly
17:38:39 <jroll> vdrok: I think that was just an idea someone through out
17:38:42 <lucasagomes> right now we require people to build a json-patch
17:38:50 <jroll> through/threw
17:38:53 <victor_lowther> and there is a difference between JSON PATCH and the PATCH HTTP method
17:39:06 <jroll> right, ok
17:39:16 <jroll> so I think JSON PATCH is better
17:39:17 <victor_lowther> https://tools.ietf.org/html/rfc6902 <-- JSON PATCH rfc
17:39:23 <jroll> if you do a GET/PUT, there could be a race
17:39:26 <jroll> and things get messy
17:39:31 <devananda> victor_lowther: AIUI, a JSON PATCH is the BODY document sent to an HTTP PATCH request
17:39:31 <lucasagomes> victor_lowther, yup we use a lib that implements that rfc
17:39:51 <lucasagomes> #link https://github.com/stefankoegl/python-json-patch
17:40:01 <rloo> i thought we wanted PUT cuz it was idempotent?
17:40:10 <devananda> building a JSON PATCH is not necessarily simple. I ran into this when taking a stab at an ansible client
17:40:30 <jroll> yeah, it makes declarative things harder
17:40:35 <devananda> as a client, I want $this information on the Node, but it has $that information right now
17:40:57 <devananda> with the current PATCH support, I have to figure out the transformation myself, in the client
17:41:04 <lucasagomes> I believe that we could make the library smarter to help with that syntax problem
17:41:04 <yuriyz> PUT with create-or-update logic is idempotent, this is a big advantage IMO
17:41:14 <lucasagomes> like creating a json-patch by diffing documents
17:41:16 <devananda> and anyone using a different client lib (or one in a different language) has to repeat that effort
17:41:36 <devananda> lucasagomes: so that would help python developers. but there are other languages in the world ;)
17:41:48 <NobodyCam> devananda: ++
17:42:10 <devananda> so at least, in this regard, adding PUT support would make things simpler for some users
17:42:36 <jroll> this might be useful btw http://json-delta.readthedocs.org/en/latest/
17:42:48 <victor_lowther> PUT is only idempotent of nothing has changed since you got the original on the server.
17:42:55 <jroll> actually
17:42:57 <jroll> https://github.com/stefankoegl/python-json-patch/blob/master/doc/commandline.rst
17:42:58 <victor_lowther> We have a mechanism in place for detecting that?
17:43:02 <jroll> same person as json patch ^
17:43:20 <devananda> victor_lowther: ooh. nope
17:43:21 <jroll> victor_lowther: no, that's one of my problems with this
17:43:30 <victor_lowther> ya
17:43:34 <victor_lowther> so
17:43:45 <victor_lowther> when updating something, send back the old one and the new one
17:43:48 <lucasagomes> jroll, nice
17:43:49 <jroll> I think devs that nee declarative things could use python-json-patch
17:43:52 <jroll> need*
17:44:26 <victor_lowther> then the server can say, sorry, try again if its copy of the resource does not match the old one you sent
17:45:12 <jroll> ... or just send a PATCH :|
17:45:21 <jroll> I don't see much value in this work
17:46:00 <vdrok> so, whats the agreement then?
17:46:08 <devananda> json-delta looks like it addresses my needs
17:46:45 <NobodyCam> *<15 minutes to go
17:47:12 * NobodyCam needs to look at json-delta more
17:47:26 <jroll> nonono, look at python-json-patch https://python-json-patch.readthedocs.org/en/latest/
17:47:28 <devananda> anyone have a strong argument in favor of PUT, such that we should do the work to support it properly?
17:47:48 <victor_lowther> PUT or PATCH a json patch, and handle it according to HTTP PATCH settings no matter how you get it.
17:48:26 <rloo> devananda: you filed the bug that may have led to that patch: https://bugs.launchpad.net/ironic/+bug/1272599
17:48:32 <devananda> victor_lowther: I mean, w.r.t. handling PUT of a whole document, not a patch
17:49:03 <victor_lowther> point and laugh at the client. :)
17:49:09 <devananda> rloo: indeed I did. and we now have support for client-side UUID creation
17:49:35 <devananda> actually, I think that bug can be closed
17:49:39 <victor_lowther> or live in an eventaully consistent world
17:50:01 <NobodyCam> *ten minutes
17:50:04 <rloo> devananda: great, let's close the bug then.
17:50:14 <rloo> vdrok: thx for all the work you put in this...
17:50:17 <vdrok> okay, then i'll update the change to put json patches?
17:50:27 <jroll> we already have patch for json patches?
17:50:36 <devananda> jroll: huh?
17:50:38 <lucasagomes> PUT a json patch!?
17:50:44 <lucasagomes> oh noes please
17:50:47 <vdrok> or abandon? :)
17:50:48 <lucasagomes> it's not needed
17:51:02 <rloo> do we want PUT for anything? doesn't sound like it?
17:51:04 <jroll> devananda: I guess that wasn't a question
17:51:16 <jroll> I vote we don't need PUT
17:51:37 <NobodyCam> sounds like we're talking our selfs out of put support
17:51:46 <jroll> yes
17:52:17 <devananda> as a user, I still feel that it would be easier to write clients for PUT, especially of subresources (like node.properties)
17:52:17 <jroll> we really need to land the state machine spec this week...
17:52:30 <lucasagomes> I see the UX benefit in having PUT (as a whole document) I just don't know if that's really needed
17:52:46 <devananda> but let's move on, since it sounds like there's agreement to not bother with PUT now, and alternatives alraedy exist
17:52:47 <yuriyz> +1 for put whole document
17:53:18 <victor_lowther> jroll: state machine scope will have to be narrowed if it is to land this week.
17:53:23 <devananda> #info no agreement on whether we should or shouldn't have PUT, but also, no clear need for it. deferring any further discussion
17:53:30 <jroll> what, why?
17:53:38 <devananda> #topic new state machine
17:53:53 <NobodyCam> I added some comments to help reviewers do just that
17:53:54 <victor_lowther> no real discussion or consensus on wait_flag
17:54:07 <victor_lowther> so that should probably be deferred until later
17:54:15 <devananda> a lot of other things depend on the state machine at this point
17:54:18 <victor_lowther> and dropped from the current spec
17:54:18 <jroll> we can't defer it, ironic doesn't work with a wait flag
17:54:23 <lucasagomes> one thing that I see on the proposed state machine is that it's too complex/hard to debug
17:54:24 <lucasagomes> for e.g
17:54:30 <devananda> so I agree, we need to focus on getting agreement on _enough_ of that so we can proceed
17:54:31 <lucasagomes> from INIT to AVAILABLE
17:54:33 <lucasagomes> you have 3 paths
17:54:38 <devananda> even if there are other aspects which take longer to flesh out
17:54:46 <lucasagomes> INIT -> DISCOVERING -> ZAPPING -> AVAILABLE
17:54:52 <lucasagomes> INIT -> AVAIALABLE
17:55:00 <lucasagomes> INIT -> ZAPPING -> AVAILABLE
17:55:11 <lucasagomes> once in available you never know from where you came from
17:55:20 <lucasagomes> it can be very hard to debug
17:55:27 <devananda> lucasagomes: maybe I'm being dense. why does that matter?
17:55:42 <dtantsur> lucasagomes, ++ and we also found that DISCOVERING may need to be _after_ ZAPPING...
17:55:50 <victor_lowther> I am cool with killing the shorter paths and allowing some of the longer states to be NOOP'able
17:55:56 <jroll> we're doing the last 2 paths in prod today, it hasn't been a problem
17:56:03 <jroll> (as a note)
17:56:08 <victor_lowther> they are in because people had use cases for them at the summit
17:56:08 <rloo> can we address that (if we need to) with a 'previous state' ?
17:56:12 <lucasagomes> devananda, well because image you have N nodes, they are same but configured different
17:56:17 <lucasagomes> some will pass, some will fail
17:56:23 <lucasagomes> and you never know the previous action
17:56:34 <jroll> logs can give you an idea, no?
17:56:42 <lucasagomes> well the idea of having a state mahcine
17:56:44 <devananda> state transition log table?
17:56:50 <lucasagomes> is that you can see what are the transitions
17:56:58 <jroll> oh god
17:57:06 <lucasagomes> and in our state machine we don;t diff states and actions
17:57:08 <NobodyCam> rloo: that seems like a lot up keep
17:57:14 <victor_lowther> I would expect we would be logging the state transitions for any given node as a matter of course.
17:57:27 <lucasagomes> we only talk about states there, we may need to think like
17:57:33 <devananda> victor_lowther: I do not think everyone shared taht assumption
17:57:33 <rloo> NobodyCam: if just the prev state, it isn't cuz to change the state to the new state, you knew what the current state was
17:57:36 <lucasagomes> to go from state A to B we need an action
17:57:51 <victor_lowther> lucasagomes: such as?
17:58:11 <lucasagomes> victor_lowther, such AVAILABLE -> [DEPLOYING] -> DEPLOYED
17:58:16 <lucasagomes> [deploying] is an action
17:58:18 <lucasagomes> not a state
17:58:25 <victor_lowther> no
17:58:37 <victor_lowther> it is a state in which actions are being performed to the node by Ironic
17:58:37 <devananda> lucasagomes: it's a state. the system is [CURRENTLY DEPLOYING]
17:58:41 <lucasagomes> http://upload.wikimedia.org/wikipedia/commons/thumb/c/cf/Finite_state_machine_example_with_comments.svg/244px-Finite_state_machine_example_with_comments.svg.png
17:58:52 <NobodyCam> i see that as a state
17:59:05 <NobodyCam> +1 it is a state in which actions are being performed
17:59:14 <NobodyCam> *one minute
17:59:16 <yuriyz> yes when deploy is running
17:59:17 <devananda> lucasagomes: the action is the user POSTing the new state to Ironic's REST API
17:59:27 <lucasagomes> http://en.wikipedia.org/wiki/Finite-state_machine#Concepts_and_terminology
17:59:28 <victor_lowther> from my POV, the actions that transition between states are API calls
17:59:44 <victor_lowther> either the REST API or direct method calls
18:00:06 <NobodyCam> *beep
18:00:14 <jroll> back to our channel :|
18:00:20 <victor_lowther> ya
18:00:22 <dtantsur> thanks!
18:00:23 <devananda> thanks all -- clearly this is a longer conversation
18:00:28 <NobodyCam> ya
18:00:36 <devananda> #endmeeeting
18:00:39 <lucasagomes> thanks all
18:00:43 <lucasagomes> yeah channel
18:00:49 <devananda> #endmeeting