17:02:32 #startmeeting Ironic 17:02:32 Meeting started Mon Mar 23 17:02:32 2015 UTC and is due to finish in 60 minutes. The chair is NobodyCam. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:32 #chair devananda 17:02:32 Welcome everyone to the Ironic meeting. 17:02:33 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:02:36 The meeting name has been set to 'ironic' 17:02:37 \o 17:02:37 Current chairs: NobodyCam devananda 17:02:43 Of course the agenda can be found at: 17:02:43 #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting 17:02:47 o/ 17:02:49 \o/ 17:02:51 p/ 17:02:53 o/ 17:02:54 o/ 17:02:59 o/ 17:03:04 #topic Greetings, roll-call and announcements 17:03:04 hi 17:03:04 Roll-call: Who's here for the Ironic Meeting? 17:03:06 lol 17:03:09 \o/ 17:03:10 o/ 17:03:11 ohai 17:03:18 o/ 17:03:18 hey all :) 17:03:19 heya 17:03:22 p/ 17:03:29 * krotscheck is a turing machine. 17:03:38 q/ 17:03:49 :) 17:04:03 win 38 17:04:07 sorry 17:04:08 ok looks like we have a full agenda today 17:04:12 #topic announcements: 17:04:14 as Devananda posted he is in Grenoble. , I hope he's having fun :) 17:04:20 JayF: wow, ditching the meeting already 17:04:40 Feature freeze in effect 17:04:45 #link https://wiki.openstack.org/wiki/FeatureFreeze 17:05:00 NobodyCam: also string freeze and dependency freeze 17:05:13 https://wiki.openstack.org/wiki/StringFreeze 17:05:20 https://wiki.openstack.org/wiki/DepFreeze 17:05:21 * krotscheck read that as string cheese. 17:05:25 rloo: yes: 17:05:36 #link //wiki.openstack.org/wiki/StringFreeze 17:05:41 #link //wiki.openstack.org/wiki/DepFreeze 17:05:47 krotscheck: mmm, now I want string cheese 17:05:51 NobodyCam: http 17:05:51 Thank you rloo 17:05:54 :-p 17:06:14 ok for my announcement 17:06:47 on IRC last week, devananda mentioned that even with string freeze, it was ok to approve string changes 1-2 days after kilo-3. Anyone know if it is too late now? 17:06:49 I wanted to thank EVERYONE for the awesome effort last week landing everything for K-3 17:06:58 Thank you one and all 17:07:06 +100 NobodyCam 17:07:19 rloo: probably a question for the i18n team 17:07:21 * BadCub seconds that! everyone was totally awesome :-) 17:07:29 jroll: ack 17:07:51 thats it for me and announcements anyone else have any? 17:08:37 NobodyCam: what about specs for L*? 17:08:38 if not we'll move on to: 17:08:48 oh 17:08:57 NobodyCam: I mean, are we going to announce when/if specs are open for L*? 17:09:11 rloo: as in they are not open yet or bumped spec from K 17:09:29 when do they open, is the quesiton 17:09:31 rloo: I do not think they are open... are they? 17:09:36 NobodyCam: yeah. I don't even remember the process for specs-approved-in-K. what do they do? 17:09:48 NobodyCam: I don't know if they are open. That's what I'm asking. 17:10:09 NobodyCam: maybe make it an action item for that-person-in-grenoble-right-now? 17:10:13 I don't think we have opened L spec yet. 17:10:19 I guess we ask the authors to move a spec to L directory 17:10:27 (and rereview it quickly) 17:10:30 I will see what I can do to track down the date for that 17:10:30 maybe let's bump this to open discussion? we talked about it some last week. can push devananda to send an email tomorrow 17:10:36 BadCub: do you remember? I saw some IRC chatter about it. 17:10:43 there was some discussion last week 17:10:52 jroll: ++ 17:10:56 devananda: was saying we need to move specs to L folder 17:11:43 NobodyCam: would you take an action item to track down the details and send email to the mail list about it? 17:11:51 #action Nobodycam find out when specs for L open 17:11:57 :) 17:12:02 thx NobodyCam! 17:12:15 anything else for #topic SubTeam: status report (deprecated) 17:12:23 gah 17:12:33 NobodyCam: if you want, I can take that action and follow-up with devananda 17:12:48 thank you BadCub 17:13:02 #undo 17:13:02 Removing item from minutes: 17:13:14 #action badcub find out when specs for L open 17:13:36 ok anything else for announcements?> 17:14:07 there is an etherpad wrt summit. 17:14:26 but i don't have the link. 17:14:31 https://etherpad.openstack.org/p/ironic-liberty-priorities 17:14:39 https://etherpad.openstack.org/p/liberty-ironic-design-summit-ideas 17:14:41 #link https://etherpad.openstack.org/p/liberty-ironic-design-summit-ideas 17:14:56 #link https://etherpad.openstack.org/p/ironic-liberty-priorities 17:15:04 thx 17:15:18 ok moving on. 17:15:20 #topic SubTeam: status report (deprecated) 17:15:21 Whiteboard wiped out, no posted status 17:15:35 I've been working on testing the API microversioning within tempest and as part of the ironicclient functional test suite. patches here, comments welcome: https://review.openstack.org/#/c/166386/ https://review.openstack.org/#/c/165665/ 17:16:16 adam_g: you have a line item for that later on down the lisr 17:16:18 list even 17:16:21 I don't think there's any big news for IPA 17:16:26 NobodyCam, oh! 17:16:29 JoshNang: did the IPA cleaning patch ever land? 17:16:36 jroll: it did! 17:16:39 sweet. 17:16:42 like, 40 hours after approval 17:16:51 :( ugggh 17:17:03 JoshNang: did it make it in k-3? 17:17:30 rloo: it's in IPA, i don't think we have a k-3 release 17:17:47 JoshNang: oh, right! (phew) 17:17:49 cleaning made it for k-3 in ironic, waiting on the nova patches for rc1 17:18:20 JoshNang: I have not look at those this morning are they still on track? 17:18:28 (the nova patches) 17:18:39 so far no activity on those (nova) patches 17:18:48 NobodyCam: i have to push up a fix for a variable name after the meeting 17:18:57 ack :) 17:18:59 but yeah, no attention yet. i'll ping in channel 17:19:08 awesome thank you :) 17:19:25 dtantsur: do you haev a bug status? 17:19:40 Open: 148. 7 new, 34 in progress, 1 critical, 14 high and 12 incomplete 17:19:47 no diff today - lost previous version 17:20:12 ya fungi is looking into what happened to our WhiteBoard 17:20:14 Open: 145 (+12) 17:20:14 10 new (+7), 33 in progress (+1), 0 critical, 16 high (-1) and 10 incomplete (+2) 17:20:15 previous week was 17:21:10 we'll be talking detail about some of those in the next section 17:21:23 thank you rloo 17:21:54 anything from driver status updates? 17:22:36 nothing notable for IPA off the top of my head 17:22:40 except cleaning support!! 17:22:47 :) w00 hoo 17:23:35 I will be hunting down drivers that are not listed on https://wiki.openstack.org/wiki/Ironic/Drivers and asking folks to update 17:23:47 ok then I expect the next section will take a bit so we'll move on to 17:23:55 BadCub: awesome. 17:24:00 thank you 17:24:07 #topic RC1 status check. 17:24:09 Goal is April 9 to cut rc-1. - https://launchpad.net/ironic/+milestone/kilo-rc1 17:24:32 looks like 11 bugs tagged for rc-1 most in progress 17:24:46 we have four currently unassigned, anyone 17:24:47 looking for something to do, volunteers? 17:24:55 #link https://launchpad.net/ironic/+milestone/kilo-rc1 17:26:06 two High and Two medium need eyes according to the status link 17:26:23 I know deva and adam_g were hacking on https://bugs.launchpad.net/bugs/1433727 17:26:24 Launchpad bug 1433727 in Ironic "partial upgrade not possible, 'reason': u'Unknown argument: "configdrive" (HTTP 400)'" [High,Confirmed] 17:26:56 also I've never seen this one to be a huge problem: https://bugs.launchpad.net/ironic/+bug/1308680 17:26:56 Launchpad bug 1308680 in Ironic "RPC receivers may starve periodic tasks" [Medium,Triaged] 17:27:16 adam_g: can we tag you as assignee? 17:27:24 NobodyCam, sure 17:27:55 on 1308680, last real comment is "but the real fix for this problem should come from oslo, making periodic tasks to run in parallel." 17:28:04 which makes me think that we can't fix this in rc1 17:28:17 unless we want to re-use dtantsur's hack for conductor-level tasks 17:28:38 yeah, Oslo is _very_ slow... 17:28:45 up to now my spec got 1x +1 17:28:51 jroll: want to comment on the bug, may be should be untagged? 17:28:51 -.- 17:29:00 i think we should bump that to L* 17:29:05 sure, I'll let deva decide if he wants to untag it 17:30:09 commented. 17:30:34 okay three more. we'll loop back to see if we can get any volunteers 17:30:47 (two more if we untag that) 17:30:49 should we see if we can get a quick status update on the assigned bugs: 17:31:01 I will follow up with devananda on https://bugs.launchpad.net/ironic/+bug/1308680 as well 17:31:02 Launchpad bug 1308680 in Ironic "RPC receivers may starve periodic tasks" [Medium,Triaged] 17:31:12 re: bug #1433727, we need to decide how we want to handle the case where a kilo nova is trying to attach a config drive to a juno ironic node. should we error the instance build or let it continue with noop'ing the config drive (like we would have done with a juno nov) 17:31:13 bug 1433727 in Ironic "partial upgrade not possible, 'reason': u'Unknown argument: "configdrive" (HTTP 400)'" [High,Confirmed] https://launchpad.net/bugs/1433727 - Assigned to Adam Gandelman (gandelman-a) 17:31:16 *nova 17:32:01 would love lucas's thoughts there, but looks like he's away 17:32:04 adam_g: I would say no-op 17:32:13 adam_g: I tend to think we should error the build 17:32:14 but others need to weigh in on that 17:32:18 lol 17:32:20 see 17:32:22 idk 17:32:25 * dtantsur summons Lucas 17:32:33 error on build 17:32:41 woot 17:32:41 sorry forgot the meeting :( 17:32:41 does the user expect a config drive or not? 17:32:43 hi lucasagomes 17:32:46 great work dtantsur 17:32:51 :D 17:32:51 * lucasagomes was busy on other stuff 17:32:52 Can we not fix the nova driver to error earlier? 17:32:58 what's up about the configdrive? I don't have the logs 17:33:03 .:adam_g:. re: bug #1433727, we need to decide how we want to handle the case where a kilo nova is trying to attach a config drive to a juno ironic node. should we error the instance build or let it continue with noop'ing the config drive (like we would have done with a juno nov) 17:33:04 bug 1433727 in Ironic "partial upgrade not possible, 'reason': u'Unknown argument: "configdrive" (HTTP 400)'" [High,Confirmed] https://launchpad.net/bugs/1433727 - Assigned to Adam Gandelman (gandelman-a) 17:33:04 i.e. to not even have a build to fail, but to prevent the build from starting 17:33:29 JayF: +1, that's what I meant, I sohuld have been more clear 17:33:41 rloo, IIRC nova can be configured to do a config drive by default,e ven if the user doesn't explicitly specify one at spawn 17:33:51 rloo, so you end up with *all* instances failing in that case 17:33:59 adam_g: :-( 17:34:06 I think it's important to fail earlier or to succeed without configdrive, i.e. if we can't keep Nova from accepting the build, we should proceed building w/o configdrive 17:34:28 JayF: that was my thought too 17:34:35 adam_g: oh, that's right :| 17:35:37 we didn't fully support config drives in juno so a operator should be expecting it be there 17:35:49 s/should/shouldn't/ 17:36:15 but what about the user. 17:36:23 in juno, even if nova asked for a configdrive we would just ignore in the ironic driver 17:36:26 because it wasn't supported 17:36:37 maybe we should do the same if we see the ironic version doesn't support it 17:36:42 just log a warning or something 17:36:55 this gets to a later meeting point re upgrades and client--we need to define how upgrade story and figure out what we support in terms of ordering component upgrades 17:37:13 I guess ignoring the configdrive would be fine 17:37:34 jroll: only for folks in juno land 17:37:47 which didn't have support for it anyway 17:37:48 right 17:37:50 :) 17:37:55 yeah, well while we don't have it, maybe checking fo TypeError? 17:38:04 NobodyCam: but the user doesn't know what version of ironic is being used :) 17:38:04 I mean if we try to pass a parameter that doesn't exist on the api 17:38:06 i think it'd be okay to ignore it under the assumption operators will eventually be upgrading ironic from juno->kilo very soon, and we ignore it only to allow things to continue working during the upgrade 17:38:17 adam_g: +1 17:38:33 adam_g, +1 17:38:34 that could be release noted 17:38:44 i do like lucasagomes idea of logging something about it 17:38:52 NobodyCam, definitely 17:38:55 adam_g: oh ya! 17:39:27 okay going to skip the detailed bug drill down for sake of time 17:40:01 please keep reviewing https://launchpad.net/ironic/+milestone/kilo-rc1 for status of rc-1 tagged bugged 17:40:10 bugs even 17:40:51 should we be adding these bugs to the review day pad since we have other rc-1 stuffs listed? 17:41:10 BadCub: ya that'd prob be a good thing 17:41:19 will do 17:41:25 Thak you 17:41:29 #topic issues needing discussion for RC1 17:41:42 mrda-away: are you really away 17:42:13 probably :P 17:42:19 so moving to adam_g 17:42:31 python-ironicclient sending version header by default 17:42:33 NobodyCam: well, I think it needs discussion. 17:42:38 NobodyCam: I mean, what mrda brought up. 17:42:48 +1 17:42:55 lucasagomes: I think you are familiar with the issue? 17:42:56 ok 17:43:09 HTTP error code changed by logical names patch -- https://etherpad.openstack.org/p/ironic-microversion-handling 17:43:17 #link https://etherpad.openstack.org/p/ironic-microversion-handling 17:43:22 rloo, well I put some thoughts on the review 17:43:40 * lucasagomes trying to remember 17:43:53 so the issue here is another upgrade snag but in the other direction, juno nova with a kilo ironic: if a juno nova is using a client /w https://review.openstack.org/#/c/165559/ merged, it will send the 1.6 header to the Ironic server during boot and get node states that it does not understand 17:44:03 I haven't read it and won't be able to in 60 secs. All I see is deva's "I think 1B should continue to raise a 400 Bad Request" at the bottom ;) 17:44:53 yeah, basically if we someone tries to GET a node by it's logical name and it's not supported 17:44:58 in Juno it would return 400 17:45:09 but in Kilo the etherpad suggest returning 406 17:45:13 which is not backward compat 17:45:23 I think the idea of the microversioning was make it look like it was before 17:45:25 lucasagomes: and what's the rationale for returning 406? 17:45:35 so the suggestion is to keep retuning 400 17:45:55 lucasagomes: wht was the objection to returning 400 17:45:55 406 not acceptable, other bits of the microversioning are using it 17:45:55 * rloo wonders when to bring up issues in meetings vs in eg mail list 17:46:09 when something that is not supported on the old version is requested 17:46:24 but I think that for this case, we should not return 406 and just keep it as it was before 17:46:48 yeah, i thought we agreed 400 must be returned to not break the API 17:46:49 otherwise we break backward compatibility and the microversioning makes little sense to prevent that 17:47:39 Shrews: oh we did? 17:47:52 I agree with lucasagomes (w/o thinking about it too much). At the very least, we can change it later (in L) if we think it should be 406. But it would be more difficult to change from 406 to 400 if we determine later that it should be 400. 17:48:04 NobodyCam: i might just be remembering a quick conversation (not an "official" agreement) 17:48:20 Shrews: ack++++ 17:48:36 the comment is here https://review.openstack.org/#/c/163730/4/ironic/api/controllers/v1/utils.py 17:48:38 but if feature X was in version 1.9 and someone used version 1.8, what should they get? 406? 17:48:47 but here I think we are agree to continue to return 400? 17:48:48 #link https://review.openstack.org/#/c/163730/4/ironic/api/controllers/v1/utils.py 17:48:53 +1 on 400 17:49:05 what if we always return 400 instead of 406? 17:49:09 also, see deva's comment on March 18 17:49:31 rloo: the difference here is, name replaces uuid in the url... it's not a new endpoint or field 17:49:49 and deva's experiment: http://paste.openstack.org/show/193128/ 17:49:53 yeah, it's a paramater and not a new endpoint 17:50:11 actually it might be the same for provision state: now some states return 406 :) 17:50:29 dtantsur, but that's fine because those states weren't supported in old versions 17:50:36 oh depends 17:50:37 hmmm 17:50:45 it isn't clear to me when to use 400 vs 406. 17:50:49 dtantsur: node_set_provision_state 'notastate' also returns 406 17:50:54 iirc 17:50:58 lucasagomes, names neither :) but the error code is different 17:51:00 yeah maybe it should be 400, because if you input an not valid state in an old version you should get a 400 17:51:00 oh 17:51:03 dtantsur, +1 17:51:06 wrt the states, before, one only expected X number of states. We've added new states that they are not aware of. 17:51:07 9 minutes 17:51:29 thank you jlvillal 17:51:54 so I think we agree on 400 in this case, but it isn't clear (to me) when to use 406? 17:52:12 rloo, right, so old versions should return 400 (BadRequest) becasue that's what old versions would do 17:52:20 as for endpoints that didn't exist before we should return 404 17:52:33 I don't see much use for 406, but I need to investigate more 17:52:46 lucasagomes: want a action item for htat? 17:52:52 NobodyCam, could be 17:53:34 #action to investigate returning 406 17:53:42 #undo 17:53:42 Removing item from minutes: 17:53:49 #action lucasagomes to investigate returning 406 17:53:56 thank you lucasagomes 17:53:58 ok 17:54:01 quickly 17:54:11 python-ironicclient sending version header by default -- https://review.openstack.org/#/c/165559/ 17:54:20 #link https://review.openstack.org/#/c/165559 17:54:34 kinda along the same lines (kinda) 17:54:41 * jroll doubts this will be quick :x 17:54:43 adam_g: thats you and devananda ? 17:54:49 ya. the problem here is we realy have no way of controlling python-ironicclient used by stable/juno nova 17:54:50 6 minutes 17:55:27 the shortest and easiest solution i can think of is to patch nova stable/juno to specify a 1.0 header 17:55:47 adam_g: right now its acting like 1.1? 17:55:51 adam_g: how sure / when can we be sure that people pick up that change? 17:56:12 adam_g: so should this patch be dependent on a nova-stable/juno patch? 17:56:24 NobodyCam, its not specifying any header so yeah, it gets downgraded AIUI 17:56:30 jroll, we can't 17:56:38 it isn't only nova that this will break though; it is all those hundreds of deployments out there ;) 17:56:50 adam_g: so we break anyone that updates the client but not ironic 17:57:00 rloo, yeah, or at least blocked ntil we have a plan on how to handle it 17:57:08 jroll, yup 17:57:20 fun. 17:57:23 ouch 17:57:25 jroll, which is the case if 165559 lands now 17:57:35 right 17:57:53 I guess patching nova-juno seems fine to me 17:58:15 so this coupled with the config drive thing begs the question: do we support partial upgrades (ie, upgrade nova without upgrading ironic or the other way around) 17:58:30 i thought we already had this discussion in one of our previous meetings. where people wanted the client to default to the latest version and I wanted none or minimum. but the rationale was that anyone that upgrades the client should only upgrade after seeing what changes were in the client. so they should know that it will/could break. 17:59:03 adam_g: yeah, we need to support partial upgrades IMO. the question to me is nova first, ironic first, or both 17:59:07 * two minutes * stendulker see my comment in ironic channel 17:59:29 jroll, adam_g: what can/do we support now. 17:59:36 jroll: ya I think we have to do our best to support them 17:59:44 jroll, with those two bugs open we can't do either right now 17:59:54 adam_g: right :| 18:00:01 oh. so no partial upgrade at all. 18:00:01 :/ 18:00:15 ok folks can we take this back to our channel? we are out of time 18:00:25 yea 18:00:28 yeah, thanks for running NobodyCam 18:00:29 let's do it 18:00:36 thank you all grat meeting 18:00:36 sorry for not being here b4 18:00:43 not at all 18:00:44 thanks NobodyCam for covering deva 18:00:54 see ya all back in our channel 18:01:03 #endmeeting