17:00:13 #startmeeting ironic 17:00:15 Meeting started Mon Apr 11 17:00:13 2016 UTC and is due to finish in 60 minutes. The chair is NobodyCam. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:17 #chair jroll devananda 17:00:18 The meeting name has been set to 'ironic' 17:00:19 Current chairs: NobodyCam devananda jroll 17:00:21 o/ 17:00:22 o/ 17:00:22 ohai 17:00:25 o/ 17:00:25 o/ 17:00:33 and of course as always our agenda can be found at: 17:00:33 #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting 17:00:43 NobodyCam is running this meeting as I'm on a flaky connection :) 17:00:44 So with that who's here for the meeting? 17:00:48 thanks for that 17:00:50 o/ 17:00:56 o/ \o /o \o \o/ 17:00:58 o/ 17:01:03 hi 17:01:05 :) 17:01:14 #topic Announcements 17:01:30 wb rloo 17:01:35 o/ 17:01:39 thx NobodyCam :) 17:01:53 summit is in just 19 days :) everyone ready? 17:02:03 Uhhhh....sure 17:02:05 o/ 17:02:06 14? 17:02:09 sure? 17:02:17 I know it starts on a monday :P 17:02:19 o/ 17:02:22 Uh 13 days 17:02:26 * jlvillal less ready 17:02:29 doh 17:02:30 also, yea, isn't it two weeks away? 17:02:45 ya I was off on my timing 17:02:54 NobodyCam is looking forward to the end of the summit I think ;) 17:03:02 lol +++ 17:03:04 :) 17:03:06 heh 17:03:25 just one annouoncement from me: 17:03:30 o/ 17:03:32 I wanted to say a quick comment on sub-team status updates. 17:03:42 over the last several meetings I have seen no-update on many of the teams items. and then details added during the meetings. 17:03:49 please try and have any updates posted to the white board at least an hour before the 17:03:57 meeting so folks have time to review and formulate any questions. 17:04:00 o/ 17:04:15 NobodyCam+++ 17:04:23 :) 17:04:42 o/ 17:04:46 thats it from me anyone else have an annouoncement 17:05:17 if not we jump right into: 17:05:29 #topic Subteam status reports 17:05:41 as always details are on the white-board: 17:05:50 #link https://etherpad.openstack.org/p/IronicWhiteBoard 17:06:17 let give folks a few minutes to review 17:06:25 o/ 17:06:43 lots of no-updates this time 17:06:58 jlvillal: any thing on nova 17:07:00 :) 17:07:19 krotscheck: betherly: anything for UI? 17:07:44 NobodyCam: v1.1 has been released. 17:08:01 betherly: \o/ 17:08:03 \o/ 17:08:08 betherly: w00t 17:08:09 addition and removal of nodes currently being worked on which potentially could even be ready for the summit 17:08:17 awesome 17:08:48 betherly: I added to the etherpad :) 17:08:52 depending on how that goes I might talk to jroll and the release people re how putting out another release would work but we will see what happens 17:09:05 NobodyCam: thanks for doing that! sorry - been a slightly ridiculous day 17:09:15 betherly: we can release master branch during this cycle at any time 17:09:17 :) 17:09:30 jroll: awesomeness 17:09:37 no promises but i will do my best 17:10:21 I see we need an ironic-lib release, I'll submit that now 17:10:25 jroll: looking at lintan's comment under oslo we'll need that for ironic-lib too 17:10:31 lol 17:10:33 ++ 17:10:33 :) 17:11:30 jroll: devananda: any eta on the Multiple compute host stuff I've been seeing some qurestions arounds that 17:11:57 eta == info (ie. general stuff) 17:12:20 we need to hammer on the claims API stuff first, that's my top thing after networking stuff 17:12:25 and then on to the nova side 17:12:38 ditto - top thing after networking is done 17:12:49 ++ :) 17:13:01 looking forward to it 17:13:38 other question / comments on status reports? 17:13:41 jroll: are there specs/code up already around that to review? 17:13:58 there is something very wip... 17:13:58 here's the ironic-lib release request https://review.openstack.org/#/c/304229/ 17:14:15 JayF: spec needs a major update, will be this week 17:14:42 jroll: worth adding that to the whiteboard section? 17:14:54 NobodyCam: line 129 17:15:04 :) 17:15:11 ++ :p blind here 17:15:32 anything else on subteam stuff? 17:15:52 moving on! 17:16:08 # topic Discussion 17:16:15 Summit session plans 17:16:20 #link https://etherpad.openstack.org/p/ironic-newton-summit 17:16:22 NobodyCam: added a space there 17:16:28 thats you jroll 17:16:31 For the "# topic" 17:16:34 #topic Summit session plans 17:16:36 doh 17:16:42 #topic Discussion 17:16:48 ty jlvillal 17:16:56 Two topics go in, one comes out... 17:16:56 #undo 17:16:57 Removing item from minutes: 17:17:02 I already got it NobodyCam :) 17:17:09 so 17:17:16 I've picked out 6 sessions so far 17:17:26 we need four more, and have a list on the linked etherpad 17:18:00 Is obvious session at bottom the six that are already decided? 17:18:12 my thoughts currently are: live upgrade, DLM, snapshots, and "how can we be more effective" (assuming we can make actionable things there) 17:18:14 yes 17:18:28 software raid is also interesting to me 17:18:56 what needs to be discussed wrt DLM? 17:19:00 my top is DLM, soft-raid, upgrades 17:19:02 Is boot from cinder/SAN/volume something worth a session? Or do we already know what we need? 17:19:02 so, curious how folks feel about those, or if they have different opinions on which we should do 17:19:09 I would put a vote in for Live upgrades 17:19:13 rloo, switching to DLM instead of our home-grown logs? 17:19:21 jlvillal: TheJulia said it should be able to be worked out in the spec 17:19:26 Okay 17:19:31 dtantsur: i thought we had already decided to switch to dlm 17:19:35 rather than just a wish-list of features, could we actually write out what sorts of outcomes we're looking for? 17:19:45 Does tooz = DLM ? 17:19:51 jlvillal, essentially yes 17:20:11 I'm curious why we think we need a session for software raid 17:20:19 is there any particular difficult problem there to overcome? 17:20:21 rloo, if everyone agrees, than we don't need a session, just someone (maybe mkovacik and I) will actually write a spec 17:20:23 devananda: re: sessions? we should, yes 17:20:29 is it a contentious topic ? 17:20:31 jroll: yea, most of htese look like feature proposals 17:20:40 dtantsur: I thought we had all agreed in Tokyo 17:20:45 I think Node anomaly detection and resolution (mariojv) +1 interested: haomeng,gabriel-bezerra, mat128 17:20:51 could be rolled into the ops session already allocated 17:20:55 devananda, I'm not sure, but ok :) 17:20:58 +1, we already agreed in tokyo about dlm 17:21:10 I assumed it was there because there's things to work out yet 17:21:12 dtantsur: yeah, I thought we had agreed in Tokyo but that it wasn't a high priority and given the state of tooz at the time, we'd do it in Newton 17:21:22 JayF, I remember someone quite opposed to software RAID, but dunno 17:21:34 rloo, aha, so my memory failed me then :) thanks 17:21:38 so if there isn't anything on DLM to discuss, I'll remove it 17:22:05 jroll++ lets have a spec for it 17:22:10 ya 17:22:19 it's not on the list but I've seen several question on multipath I/O support 17:22:28 I don't think we need a whole session on "FSM error states" too 17:22:30 also the inspector HA discussion will involve tooz/dlm 17:23:10 NobodyCam, oh god yes.. but is it something we can do within ironic? other than passing a correct root device? 17:23:15 * dtantsur is clueless to be honest 17:23:29 worth a session? 17:24:00 I don't know that it's worth a session 17:24:06 dtantsur: I'm in hte same boat as to how much we can support 17:24:13 I think it is worth a short fast discussion 17:24:13 given we've barely talked about it so far 17:24:22 idk if folks have enough context for a session (I don't) 17:24:24 I believe we have the experteise to grasp and understand it in ~30 minutes 17:25:02 sessions are a good way of filling in context for folks 17:25:06 But, we could also go get a cup of coffee and work through it since it is really just fallback root device selection logic I think 17:25:33 so I agree with some of the notes on the etherpad and have removed live upgrades and multi-compute things 17:25:35 maybe some kind of open discussion session... thou those can go sideways quickly 17:25:37 I'm more than happy to drive such a discussion and context overload 17:25:47 TheJulia++ 17:25:50 leaving us with four sessions to choose from for four slots 17:26:05 so... I think we are done if people are okay with those four being on the schedule? 17:26:10 specifically: 17:26:19 live upgrades 17:26:29 anomaly detection stuff 17:26:34 snapshotting 17:26:38 how can we be more ffective 17:26:42 oh, why are we removing live upgrades? 17:26:44 +1 17:26:59 rloo: no, those are the four left 17:27:00 rloo: I think those are the ones that will get sessions. 17:27:00 is upgrade there? 17:27:16 jroll: oh, i misunderstood. good that it is there :) 17:27:21 ya :) 17:27:30 I'm good with those four :) 17:27:33 I like them. More effective and live upgrades are both very interesting to me. 17:27:33 +1 17:27:44 jroll: I'm not keen on snapshotting -- what's there to discuss? 17:27:47 Though I realize being more effective is probably a difficult them to figure out... 17:27:48 * jroll waits about two more minutes for objections 17:27:56 devananda: all the insanity about "cleaning the image" 17:27:56 s/them/thing/ 17:28:11 jroll: how does Nova do that? 17:28:12 devananda: "'reset/unconfigure' copied disk to reset the image, removing SSH host keys, removing persistent network MAC configuration, and removing user accounts etc." 17:28:22 yea, uh, how does Nova do that? 17:28:37 I don't see how that is different for Ironic 17:28:47 what _is_ different is trying to clone that image across different hardware 17:28:48 I feel like it doesn't, I'm unsure 17:28:50 if instance_id != known_id 17:29:06 basically cloudinit checks and rebuilds _stuffs_ if the instance_id does not match what it knows 17:29:11 devananda: we heavily rely on cloud-init running 17:29:15 orly 17:29:20 interesting 17:29:27 I'm -0 on snapshotting. I don't have a context just as well, and the proposer is not attending the summit 17:29:51 I'd rather see us talk about multipath, if I had to choose 17:29:52 dtantsur: oh 17:29:54 yeah, that's fair too 17:29:54 I like the idea of snapshooting, but "cleaning/resetting/reconfiguring" the image just seems... wrong to me 17:29:59 if the proposer is not there, I am -1 on discussing it 17:30:15 if the proposer were there, is snapshotting something we'd want in newton? 17:30:16 I'm referring to line 54 17:30:28 s/the proposer/someone capable of representing the design proposal/ 17:30:34 snapshotting is something I continue to hear requests for 17:30:41 rloo, provided the amount of huge changes we plan on? I doubt 17:30:51 dtantsur: huh. I did not write that 17:31:18 devananda: right, haomeng was asking if you could run it :P 17:31:22 anyway 17:31:39 snapshotting is what's left, if folks would prefer something else, I'm good with that 17:32:03 mat128: ohhai :) 17:32:05 hey there, I'm late :( 17:32:08 software raid, multipathing, FSM error states, others are all options 17:32:09 might be a good place to get context for mp io stuff 17:32:34 * TheJulia can handle context sharing if we have session 17:32:35 jroll, of these - multipath. otherwise I'd talk about ansible driver, but we ruled it out 17:32:41 have we got a session for boot from volume ? 17:32:42 I like the idea of an open topics session, allows for discussions that pop up during the week, as long as it is moderated 17:32:44 shold we (#) vote for te last session 17:32:58 dtantsur: I'm also fine with ansible driver 17:33:04 krtaylor: I generally like keeping those to hallway track, tbh 17:33:07 jroll: ++ ansible driver session 17:33:11 are there any cross-project initiatives that we need to discuss wrt ironic? 17:33:12 dtantsur: thinking more about it, those folks are in the same shoes us agent people were in 17:33:32 JayF, krtaylor: or friday's slot 17:33:43 rloo: we have two of those already scheduled, I believe 17:33:44 or a session where we go over/discuss eg 4? specs 17:33:57 I'm also -0 on "how can we be more effective" FWIW. we can talk about it with beer later in the evening 17:34:02 devananda: ok 17:34:10 dtantsur: ++ 17:34:19 TheJulia: do you feel there's a need to have (another) session on cinder integration? 17:34:23 dtantsur: wrt the effective, we could talk about it over beer, but i'm interested in what is slowing down reviewers, and what is slowing down developers 17:34:47 rloo, great topic for beer! also, we had this kind of discussion numerous times... 17:34:51 dtantsur: i could also start an email discussion. 17:35:02 ++ for email discussion 17:35:04 I think it's good to revisit sometimes 17:35:12 we've had discussions between various people. i am hoping for guidelines or some consensus 17:35:12 * thiagop thinks that beer is better than e-mail :) 17:35:19 also keep in mind there's some people that don't go out at night 17:35:31 or might be more apt to speak up during a session 17:35:41 also, it is hard to have a big group participating in one discussion over beer 17:35:42 I'm +1 on a "real" session for it 17:35:47 yep 17:35:49 jroll, of what I know about people, they tend to speak more with beer 17:35:50 Yeah, I mean, honestly, if I think it's something we need to officially chat about (like efficiency as a team), I'm -1 about just trusting "over beer" for it 17:36:01 as I think that will lend to the same voices getting heard as usual 17:36:02 dtantsur: some do, some do not 17:36:12 maybe we need the beer session before the actual session :) 17:36:14 "if I think it's something we need to officially chat about" I don't 17:36:14 * NobodyCam notes that there are a couple things still up in the Open discussion section 17:36:16 some do not feel comfortable in a drinking environment 17:36:36 NobodyCam: yep, and I'm at 8% battery 17:36:37 devananda: wrt cinder, I really don't think so since in some ways we would just be emulating things already done :) 17:37:04 about cloning/snapshotting, just read that haomeng won't be at the summit and I can't go either, wanna use that session for efficienty as a team in a more formal context? 17:37:24 so I've locked in live upgrades and anomaly detection 17:37:25 so my vote for the final 4 sessions: multipath, live upgrades, ansible driver, anomaly detection (in this order) 17:37:47 JayF: agree with that point, although I fear we will just bikeshed on how we can do better 17:37:50 and I'm thinking effectiveness and ansible for the other two 17:37:58 but let's come back to that tomorrow in irc or ML 17:38:29 TheJulia: cool, that was my impression 17:38:32 I really think anomoly detection can go into the ops session I'm already running 17:38:38 jroll: sorry, come back to what tomorrow? 17:38:42 unless there's a subtext there I'm missing? 17:38:42 jroll: 3rd party CI status? 17:38:48 so move on to Open discussion 17:38:55 rloo: the last two selections 17:39:02 oh 3rd party ci is a good topic 17:39:03 jroll: oh, i see that's under the Gate topic 17:39:04 devananda: sure, maybe 17:39:13 isnt that in the QA session? 17:39:14 any reference on multipath? 17:39:17 would that be worth its own session, if we can get thingee to join us? 17:39:19 jroll: ah. ok, but not irc. ML. that'll give people who aren't present, a chance to voice their opinion. 17:39:23 krtaylor: oh, is it? 17:39:25 I'd like to understand it better 17:39:29 yeah, it's good, but we probably don't need to spend the whole session 17:39:44 devananda: possibly. not sure. I don't like all the new sessions being proposed at the last minute :/ 17:39:50 devananda, yes, sorry, labeled gate session 17:39:52 like to move on in one minute 17:39:53 we have a pretty good plan for 3rd party CI, we just have to make sure people are on track and don't have blockers 17:39:57 we need these locked in by friday 17:40:15 NobodyCam: ++ let's move on and I'll take this to the ML 17:40:22 ++ 17:40:26 #topic Open discussion 17:40:31 we have a couple items here: 17:40:37 zhenguo_: that you 17:40:42 thats* 17:40:43 hi 17:40:51 I have an extra item for open discussion, if we end up having time. 17:40:55 I would like to discuss about the serial console stuff 17:40:58 dtantsur, I can summarize where we are at in the gate session 17:41:13 krtaylor, awesome 17:41:28 zhenguo_: is there a review we can link to this 17:41:49 yeahhttps://review.openstack.org/#/c/300582/ 17:42:01 #link https://review.openstack.org/#/c/300582 17:42:33 we have two options : one is add a custom HTTP proxy on nove side to leverage the shellinabox console 17:42:47 another one is add a new console driver to replace shellinabox 17:42:54 my battery is gone, so I need to bounce, but IMO I'd rather not add a new proxy to nova, consistency for users is key 17:43:05 I invited mriedem here to join this discussion as he has similar feelings, I suspect 17:43:07 another thing that might be relevant - one of our guys has a wip patch with vnc console - https://review.openstack.org/296437 17:43:10 jroll: ++ 17:43:20 jroll: ++ and ack 17:43:32 but alas I need to go, thanks for the good meeting y'all, thanks NobodyCam for running things 17:43:36 see y'all tonight/tomorrow 17:43:36 i'd prefer not adding a new console proxy in nova, yes 17:43:38 I guess the question I would have w/r/t shellinabox is what was the reason it as chosen originally 17:43:50 * TheJulia just lacks that context 17:43:55 TheJulia: we inherited it from the old nova-baremetal driver 17:43:59 and, fwiw, it worked in Nova back then 17:44:06 mriedem: but I think it's may also benefit for other drivers' web based console 17:44:06 I personally liked the socat implementation for serial cli console 17:44:07 ~ Folsom era 17:44:23 vdrok's review is super interesting 17:44:33 So sounds like we just ned to move on and be in sync with what nova is doing now :\ 17:44:37 s/ned/need/ 17:44:40 we haven't had CI testing of it, though, and I am unaware of what may or may not have changed on the Nova side that caused our shellinabox console driver to stop working 17:44:40 AFAIK not all aten provide a native VNC like that (supermicro doesnt) 17:44:50 TheJulia: exactly 17:45:06 mat128: not actually mine :) IIRC I was said it's tested on supermicro 17:46:26 I don't have the context to weigh in on console stuff as it impacts nova 17:46:55 but I can see that work requiring a spec 17:46:59 We have graphical console stuff running and the only nova change is start console / get console stuff 17:47:02 no proxy 17:47:18 mat128: ++ can you link the review 17:47:24 https://bugs.launchpad.net/ironic/+bug/1567629 17:47:26 Launchpad bug 1567629 in Ironic "[RFE] Nova graphical console support" [Undecided,New] - Assigned to Mathieu Mitchell (mat128) 17:47:26 mriedem: nova uses novnc as a proxy to the hypervisor's console implementation, right? 17:47:28 drafting up the spec unfortunately 17:47:36 devananda: thats correct 17:47:56 devananda: nova have some different console proxy 17:48:05 we end up running a `display driver` in a docker container 17:48:09 essentially IPMIview + x11vnc 17:48:27 mat128: interesting RFE 17:49:00 Hi everyone, I also proposed a spec for this serial console stuff 17:49:06 Here is my spec https://review.openstack.org/#/c/296869/ 17:49:09 very interesting since it would help users run things that don't have a serial port console 17:49:17 I propose to add an IPMI proxy (ironic-ipmiproxy) to help connect Nova-serialproxy and bare metals 17:49:18 Heh maybe console needs a design summit session, lol 17:49:18 I guess such "display driver container" could do the transformation between ipmitool console and a nova-compatible console 17:49:25 relieving ironic-conductor of such duties 17:49:32 JayF, lol, it looks so 17:49:35 JayF: yeah... 17:49:48 can we add all the reviews to the agenda and keep it there until next week giving folks time to review 17:49:50 < not at the summit :( 17:50:03 but wont prevent anyone from having the discussions :P 17:50:14 I'd like to make sure we have time for vdrok's Node name updates topic 17:50:19 NobodyCam: good idea, will make sure I finish my spec 17:50:20 NobodyCam: agree 17:50:20 actually, this looks like a good summit session IMO 17:50:22 mat128: when will your specification be available? 17:50:36 this week for sure 17:50:40 awesome! 17:50:44 because we have several different proposals, and we also need to understand how Nova is currently expecting to interact with the functionalty 17:50:44 just have to finalize both specs 17:50:58 we're essentially already running this, so it's more describing than solving new issues 17:51:06 devananda: that too! can you address in the ML thread 17:51:08 +1 on summit session for serial console 17:51:11 This is another console related proposal, https://review.openstack.org/#/c/293871/ 17:51:13 ++ 17:51:17 ++ 17:51:31 at least it is clear that folks want this feature :) 17:51:37 yes! 17:51:39 mat128: from a quick read of your RFE, it looks like it is very specific ot your ipmlmentation and would need to be abstracted somewhat 17:51:49 jroll leaves for 10 minutes and look what happens to his summit schedule ;) 17:51:57 lol 17:51:59 yea, clearly a feature a lot of folks want :) 17:52:01 lol 17:52:13 we will have a ML thread so he can catch up 17:52:15 * thiagop watches clock 17:52:16 I, for one, do not yet understand the differences between these proposals 17:52:21 and would like to 17:52:24 (but not right now) 17:52:29 agreed 17:52:36 lets more on to Node name updates ! 17:52:42 vdrok: thats you 17:52:46 #link https://review.openstack.org/300983 17:53:02 here is the patch, there are 2 bug resolved 17:53:28 first one being - forbid node name removal if api version is < 1.5 where names were introduced 17:53:42 this changes return code 200 to 406 17:54:25 I've put -1 on that patch as it looks like an API break to me.. 17:54:25 second one being checking the final name that is requested in PATCH so that it is not impossible to do ironic node-update node add name=abc name=&*^&*^ 17:54:40 that changes 200 to 400 in this case 17:54:57 yep, there also is a today's thread about it 17:55:19 on the one hand it is api break, on the other - both are bugs that should be fixed I think 17:55:37 I was reviewing that just before the meeting ... 17:56:12 vdrok: why do we have to absolutely prevent an operator from setting a name using the old version? 17:56:15 IMO, first one is clearly a fix and is OK to land without API bump. second one is less clear to me. 17:56:31 just questioning the requirement, since it makes a 2xx become a 4xx 17:56:56 mat128: the node name isn't included in the response body to a GET request for api v < 1.5 17:56:56 mat128: that's why we added api microversions in the first place :) 17:57:12 devananda, for me it's the opposite. removing ability of removing the node name has much higher chances of breaking people 17:57:13 mat128: a request to add or change the name will be rejected, but a request to remove the name gets accepted 17:57:17 devananda: thats perfect since it wont break old clients 17:57:25 shouldn't the second one be for any duplicated parameter on update? 17:57:27 i think a review of how we hide / remove thing from privious api versions would good in general 17:57:37 vdrok: it's just a new feature, hidden from old clients. In some specific way, you can push a name update on the old API, but you really have to know how 17:57:43 devananda: you mean doing 2 subsequent name updates and checking only the last one? 17:58:03 vdrok: sorry, I was referring to the first issue (old client can remove /name) 17:58:08 *FYI: two(2) minutes t go* 17:58:08 mat128: currently you can only remove name with old api version 17:58:19 devananda: ah, gotcha 17:58:21