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