17:00:04 #startmeeting Ironic 17:00:04 #chair devananda 17:00:04 Welcome everyone to the Ironic meeting. 17:00:04 Meeting started Mon Jun 1 17:00:04 2015 UTC and is due to finish in 60 minutes. The chair is NobodyCam. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:07 The meeting name has been set to 'ironic' 17:00:08 Current chairs: NobodyCam devananda 17:00:14 o/ 17:00:14 Of course the agenda can be found at: 17:00:15 #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting 17:00:22 #topic Greetings, roll-call and announcements 17:00:22 Roll-call: Who's here for the Ironic Meeting? 17:00:30 \o/ 17:00:46 o/ 17:00:56 o/ 17:00:58 o/ 17:01:03 we may have folk joining late as there is a neutron / ironic meeting just ending in OS-meeting-4 17:01:09 hi 17:01:15 o/ 17:01:15 \o hello hello 17:01:16 welcome all 17:01:21 o/ 17:01:36 #topic announcements: 17:01:39 Devananda is in Las Vegas at HP Discover promoting Ironic 17:01:53 we all survived the summit 17:01:56 * dtantsur fixes to "HP Inspect" automatically 17:02:23 lol! 17:02:23 o/ 17:02:28 o/ 17:02:30 dtantsur: LOL! 17:02:38 <_lintan> o/ 17:02:41 o/ 17:02:55 o/ 17:02:55 and yes, I'm in the belly of the beast 17:03:08 welcome back everyone. :) 17:03:11 and let me tell you, it smells 17:03:20 hehheh 17:03:46 any announcements before we start the ball rolling? 17:04:13 there were a few large discussion threads started last week relating to ironic. I dont have all the links prepared - but I hope everyone is watching the -dev mailing list and saw them 17:04:34 * devananda has no announcements 17:04:37 #link http://lists.openstack.org/pipermail/openstack-dev/2015-May/065072.html 17:04:56 that is a link to the summit recap email devananda sent out last week 17:05:03 Thank you devananda :) 17:05:51 #topic SubTeam: status report are posted on the Whiteboard 17:05:52 #link https://etherpad.openstack.org/p/IronicWhiteBoard 17:06:03 thank you all for the updates 17:06:33 looks like 3rd party ci is almost ready for the iLo drivers ... awesome news 17:06:46 irmc seems to be the only new update for this week? 17:06:50 NobodyCam: that looks old 17:06:57 dtantsur: looks like the bug section is overdue for an update 17:06:58 "hopefully will be done before summit" 17:07:05 "doh" 17:07:30 devananda, yeah sorry, it was a busy aftersummit week 17:07:35 dtantsur: indeed :) 17:07:42 devananda, I did triage a couple of bugs, but I forgot to update the stats 17:08:00 on the topic of third party CI, we are going to need some central place to consolidate periodic CI job runs 17:08:19 feedback that I've gotten is that many of hte vendors wont be able ot keep up with the patch rate -- iow, they cant test every patch 17:08:33 :( 17:08:50 and so we need to create a "place" where periodic 3rd party CI jobs can post results AND where we'll all see it 17:08:55 so we can, you know, spot failures 17:09:03 if not proactively, at least reactively 17:09:07 * dtantsur updated whiteboard 17:09:11 there was a session on that at summit 17:09:11 can they test *only* gate/merges? or is that even too many? 17:09:11 dtantsur: ty 17:09:14 dtantsur: TY 17:09:15 https://etherpad.openstack.org/p/YVR-QA-testing-beyond-the-gate 17:09:38 rloo: some might be able to, yes 17:09:45 #link https://etherpad.openstack.org/p/YVR-QA-testing-beyond-the-gate 17:09:56 that is a periodic dashboard proposal 17:10:26 rloo: but there is the further need for us to have periodic jobs *anyway*, eg for other upstream things like upgrade testing that takes 2 hours per run 17:10:27 krtaylor: awesome I will try and look afterthe meeting 17:10:29 we have several 3rd party requirements to be able to push results, non-gerrit patch based 17:11:02 yeah, it would be good to have periodic jobs 17:11:56 rloo, what's the use of testing in gate? if it's voting, it will annoy people whose patch just got approved. If it's non-voting it's the same as just running a job on master from time to time - it won't help a reviewer 17:11:58 if we have time lets come back to this 17:12:00 thanks for the link, krtaylor. good stuff 17:12:12 sure, np, I think it will be a requirement for us to start having in-tree/out-of-tree discussions, start with periodic 17:12:23 dtantsur: to be able to pinpoint when/if a particular patch causes the failure. 17:12:53 hmm, right 17:12:55 rloo: dtantsur: Wouldn't periodic just run against the tip? 17:12:56 dtantsur: a non-voting test run on the gate could still be used to isolate a change that introduced a failure to a single patch, rather than a window of time (test_time - last_successful_test_time) 17:13:12 understood, thanks :) 17:13:16 jlvillal: yeah, it'd run against tip but then you'd need to see 'what changed' since last test 17:13:28 let's move on -- I think we all agree we need to have a place to collate periodic job test results 17:13:31 rloo: Okay. 17:13:47 ok moving on. 17:13:51 #topic Neutron meeting recap 17:14:02 jroll: can you cover this one 17:14:08 ohai 17:14:20 so we had the first ironic/neutron integration meeting this morning 17:14:31 it went pretty well overall and we made some good plans 17:14:54 jroll: thx for covering that [while I was on a plane] :) 17:15:04 there will be specs incoming from BertieFulton and myself this week, around "how do we store physical network info" and "how do we flip around networks", respectively 17:15:19 we *shouldn't* need nova/neutron specs for this stuff, but we might. there will be nova changes. 17:15:45 be on the lookout for those specs! 17:15:51 that's all I have for now, I think 17:15:53 devananda: np :) 17:16:06 awesome stuff jroll 17:16:08 Thank you 17:16:19 jroll: i guess we just need to be mindful if we need nova specs, to get them in before the cutoff date 17:16:33 looking forward to all the new toys for ironic 17:16:37 rloo: oh, we will :) 17:16:39 ++ what rloo said 17:16:53 rloo: I've already started on nova patches to stay ahead of the game 17:17:13 jroll: awesome! 17:18:09 shall we move on? 17:18:10 any questions for jroll (or anyone) on this? 17:18:16 ack 17:18:18 jroll: do we consider neutron/ironic a 'subteam'? (wondering if we want weekly status) 17:18:53 ++ for weekly status 17:18:53 rloo: idk, I'm happy to give weekly updates 17:18:55 * jlvillal would vote +1 17:18:58 there is a separate IRC meeting for this effort - so yea, I'd call it a subteam 17:18:59 I was expection we would just bug jroll for status' as he did the first one 17:19:04 whether official subteam or whatever 17:19:06 lo 17:19:07 cool 17:19:15 ok moving on. 17:19:17 ok, adding it to our etherpad/subteams 17:19:31 ty rloo 17:19:31 ty 17:19:41 #topic Should Ironic modify filesystems on disk 17:19:52 this was added by jayf 17:20:00 is he here? 17:20:07 the spec has been up for over a month now 17:20:27 #link https://review.openstack.org/#/c/173142 17:20:38 it has a -2 on it 17:20:46 I've objected to it, and JayF has -2'd it, because it proposes that IPA mount every file system on the host, scan for a file named "fstab" and then modify that file 17:21:05 writing the configdrive as a raw file and creating a loopback device for it 17:21:10 * NobodyCam would vote -2 17:21:33 we should not touch users files 17:21:37 to apparently get around issues that one operator is having with configdrive partition taking up more space than they want to give it 17:21:41 welcome JayF 17:21:54 and/or avoid having too many primary partitions 17:21:56 hey, sorry for being late 17:22:04 would be good to have the submitter of that spec here too 17:22:17 JayF: #topic Should Ironic modify filesystems on disk 17:22:23 I'm also -$vote on this, fwiw 17:22:30 whether that's -1 or -2 17:22:30 rloo: indeed, but I don't see jxiaobin anywhere on IRC 17:22:42 devananda: maybe they didn't know (or diff time zone). 17:22:48 My primary concern is that today we don't touch filesystems on disk at all, and it's a support matrix I'm not sure we should take on 17:22:52 timezone may make that hard. IIRC, he is in korea 17:23:03 I haven't read the spec, but if we can address the person's concerns some other way, seems like that would be better 17:23:15 This spec is basically to satisfy one user's use-case? 17:23:17 The idea of not only writing out a file to disk, but modifying configs makes Ironic have knowledge distribution/OS + filesystems required 17:23:27 moreso than it does today 17:23:36 I believe the boundary between user data and operator control plane needs to be (at least within upstream codebase) inviolate 17:23:49 there are clearly defined APIs for passing data into the user's instance (read: cloud-init) 17:23:58 but going in and mucking with /etc/fstab is NOT one of them 17:24:11 devananda: ++ 17:24:15 ++ 17:24:19 ++ 17:24:25 ++ 17:24:28 ++ 17:24:29 ++ 17:24:33 ++ 17:24:40 ++ 17:24:41 ^^ 17:24:48 heh. well. that's pretty clear :) 17:24:49 so this spec needs to be re-worked 17:24:56 that seems fair enough. I see that jxiaobin is a new contributor so perhaps someone can spend a bit 'more time' than normal communicating/discussing with them? 17:25:10 Anyone who was here for mid-cycle-alt in SF met them 17:25:14 that's the group of folks from Ebay 17:25:15 * jroll touches his nose 17:25:27 * JayF doesn't have the time 17:25:36 * rloo thinks she understans jroll's reference... 17:25:43 #agreed ironic should not cross the user-data/operator-control-plane boundary and start editing files within the user's instance directly; it must rely on existing APIs for that (eg, cloud-init) 17:25:53 Ty devananda :) 17:25:56 rloo: touch nose = "not it" ... as in last person to touch their nose *is* it 17:25:59 rloo: https://en.wikipedia.org/wiki/Nose_goes 17:26:07 ok is pshige here 17:26:27 jroll: i was wrong, i think (some) asians do that to refer to 'themself'. Ie, you're it. 17:26:31 NobodyCam: pshige stated not feeling well and skip to next week. According to agenda 17:26:44 ya was just checking 17:27:01 so next up is: 17:27:06 #topic Should remainder of PEP8 compliance work be done? 17:27:09 rloo: interesting, TIL :) 17:27:11 jlvillal: thats you 17:27:22 sambetts: Has started the work on this. 17:27:25 #link https://bugs.launchpad.net/ironic/+bug/1421522 17:27:25 Launchpad bug 1421522 in Ironic "Ironic code ignores all E12* pep8 errors" [Wishlist,In progress] - Assigned to Sam Betts (sambetts) 17:27:35 jlvillal: so I'm curious what E126,E127,E128 are 17:27:39 I just wanted to make sure that everyone is okay with it. As it will likely touch a lot of code 17:27:58 jroll, IIRC indentation 17:28:03 jroll: http://pep8.readthedocs.org/en/latest/intro.html#error-codes 17:28:03 E123 (*) closing bracket does not match indentation of opening bracket’s line 17:28:06 E126 (*^) continuation line over-indented for hanging indent 17:28:09 E127 (^) continuation line over-indented for visual indent 17:28:12 E128 (^) continuation line under-indented for visual indent 17:28:12 I presonally hate the indentation rules 17:28:18 meh. I dont see any significant value in those 17:28:23 i would vote -1 for 128 17:28:32 I hate the rules, but I hate when they're violated all over the place 17:28:40 there are a LOT of cases where readability is improved, IMNHSO, by ignoring those 17:28:45 dtantsur: ha ha, that doesn't make sense! 17:28:49 devananda: +1 17:28:53 I would vote for consistency and OpenStack states code should be PEP8 compliant 17:29:00 I also find I spend significant time tweaking things to fit those rules 17:29:05 eg, because line wrapping to 80 chars of some highly indented code would make one expression span a bagillion lines 17:29:08 or three 17:29:11 either way it's too many 17:29:11 But I may be in minority :) 17:29:31 for the record: inspector never ignored any pep8 rules 17:29:47 python-ironicclient is fully PEP8 compliant also. 17:29:47 so I'm generally on the positions of: rules might such, but they're rules 17:29:57 I don't see a problem with being pep8 compliant personally 17:30:10 s/such/suck/ 17:30:12 off hand, I think E128 is the one I would want to continue ignoring 17:30:39 for the record, E129 isn't there cuz lucas? and I objected to it 17:30:52 I'm probably at fault for breaking E123 all over the place. hang over from my C / Perl days 17:31:01 yea I'm okay will all but the 128.. 17:31:12 tl;dr; do these rules improve readability when we follow them, or when we break them? 17:31:47 the patches to fix 123, 6 7 and 8 are up for review, and I think there are several cases when it does improve the readablity of the code 17:31:57 hm 17:31:57 i looked at part of one of the patches, and it improved it for some cases 17:32:04 I think they improve readability for the most part. 17:32:11 ok then 17:32:12 sambetts: can you #link them here for the record 17:32:18 I don't think we can see it does it for all cases. But in the aggregate... 17:32:19 and if the refactoring is already done, then yea, I'm for it. 17:32:34 s/see/say/ 17:32:35 it will cause some rebasing of other patches immediately -- better t oget that out of the way if we are going to enable these checks 17:32:36 The top of the tree of patches: https://review.openstack.org/#/c/186021/ 17:32:49 #link https://review.openstack.org/#/c/186021 17:33:20 Did we make a final decision on E128? Yay or nay? 17:33:25 I'm good with what ever direction we want to go.. should we vote? 17:33:36 I think the patch is already doing E128 17:33:45 isn't that the bottom of the tree of patches? (what is top vs bottom?) 17:33:50 if the works done, I'm fine with it 17:34:02 rloo: yes, thats probably true 17:34:13 umm, i'm not fine with it w/o looking at it 17:34:22 First patch to review is 186021 as all the others depend on it. 17:34:26 #startvote should we enable E123,6,7,8 checks? yes, no, abstain 17:34:27 regardless if the work is done or not ;) 17:34:27 Begin voting on: should we enable E123,6,7,8 checks? Valid vote options are yes, no, abstain. 17:34:28 Vote using '#vote OPTION'. Only your last vote counts. 17:34:37 #vote yes 17:34:40 #vote yes 17:34:42 #vote yes 17:34:42 #vote yes 17:34:43 #vote yes 17:34:45 why all or nothing? 17:34:56 #vote abstain 17:35:00 rloo: you can abstain or vote no if you dont want all 17:35:01 #vote yes 17:35:02 #vote yes 17:35:05 #vote yes 17:35:06 #vote no 17:35:09 <_lintan> #vote abstain 17:35:09 #vote abstain 17:35:09 #vote yes 17:35:19 #vote no 17:35:26 #vote abstain 17:35:32 #vote yes 17:35:43 #vote yes 17:35:57 I just don't like the continuation indent rules 17:36:03 giving it another minute 17:36:34 or not - since it seems everyone is done voting now :) 17:36:37 #endvote 17:36:38 Voted on "should we enable E123,6,7,8 checks?" Results are 17:36:39 yes (11): TheJulia, NobodyCam, jlvillal, afaranha, devananda, jroll, dtantsur, Nisha, natorious, sambetts, thiagop 17:36:40 abstain (4): cinerama, BadCub, _lintan, gabriel-bezerra 17:36:41 no (2): rloo, clif_h 17:37:00 I think the ayes have it 17:37:01 we've got 1 core voting no, 1 core abstaining 17:37:10 4 cores voting yes 17:37:17 and overall a lot more support for yes 17:37:44 yep 17:37:46 #agreed enable E 123,6,7,8 checks 17:37:46 (who's the core that abstained?) 17:38:04 rloo: oops! I misread. we have no cores abstaining 17:38:10 :-p 17:38:20 ok moving on 17:38:20 * BadCub hands devananda more coffee 17:38:27 #topic Ironic Mid-Cycle Sprint 17:38:34 I think is is BadCub 17:38:39 BadCub: thanks. remind me to never sit in a casino while trying to pay attention to IRC again 17:38:40 Yep 17:38:50 devananda: lol noted! 17:38:51 lol 17:39:03 So folks. Sprint.... Seattle work for everyone? 17:39:14 ok so, "It's near the feature freeze. It might be a little late." <- first question, do we want to change release models this cycle or next 17:39:16 * NobodyCam hands deva some $$$ for the closest slot machine 17:39:24 I'm +1 on seattle though 17:39:31 devananda: when they ask for your drink order, ask for coffee :) 17:39:39 Works for me, but I will be in Moscow for all of July.... 17:39:39 +1 on seattle 17:39:39 devananda: advised he would get in touch with facilities at HP 17:39:51 I've pinged the local facilities mgr, but no answer yet 17:39:52 north america does not work for me, so abstain on seattle :) 17:39:58 * jlvillal assumes he will get visa.... 17:40:09 dtantsur: france didn't work for you last time, either :( 17:40:13 dtantsur: You can come to Moscow and we can have mini-sprint ;) 17:40:22 jlvillal: visa's from protlanda are hard to get I hear 17:40:50 s/protlanda/portlandia 17:40:50 devananda, yes, you can safely assume that generally midcycles do not work for me :) in EU there are some (small) chances though... 17:40:56 :) 17:40:57 So what about timing? devananda proposed 12-14 Aug, but that is close to freeze 17:41:02 Is there a date range? 17:41:11 so I ask again, are we having a freeze this cycle? 17:41:26 read: switching release models this cycle or next? 17:41:27 jroll, I was assuming we follow our new model 17:41:36 me too, which means freeze doesn't exist :) 17:41:43 fwiw, I'm looking at dates of Aug 12 - 14, which is the week before LinuxCon / CloudOpen in Seattle 17:41:46 I have a secondary discussion item about spec review freeze later as well 17:41:52 http://events.linuxfoundation.org/events/linuxcon-north-america/extend-the-experience/co-located-events 17:41:58 +1 on dates and location 17:42:01 did we decide for sure to use new release model? thought it was still in proposal stage 17:42:21 BadCub, I thought that in a new model we don't have spec freeze, but maybe it's only me :) 17:42:29 rloo: we all (soft?) voted on it in vancouver, I was under the assumption this was an informational spec 17:42:33 jroll: I would like to land: https://review.openstack.org/#/c/185171 17:42:36 fwiw 8/12-8/14 I wouldn't be able to attend; but I'm OK with that 17:42:37 rloo: I don't see disagreement on the list either 17:42:41 dtantsur: I thought that too 17:42:48 jroll: give me a day or two... 17:42:51 dtantsur: yeah, I put it up there for us to confirm that we are going to follow new model 17:42:55 that is ok for me i think 17:43:05 on the topic of release cycle / freeze / etc -- I dont know yet. I'd *like* to not do a feature freeze, *but* we are somewhat dependent on how far the community gets in changing the release models 17:43:13 adapting their release tooling to support it 17:43:18 NobodyCam: same. 17:43:30 NobodyCam: needs some updates, I'll get to that this week 17:43:39 jroll: +++ 17:43:41 so far, it looks like dhellmann is on the ball with all that, and ttx has already announced changes to how we'll track/report on release cycle progress 17:43:52 so, it looks possible (if not likely) that it'll happen this cycle 17:44:11 which means we're having a release soonish :) 17:44:20 dtantsur: eh? 17:44:26 so [assuming] we will follow the new model. Is everyone good with 12-14 Aug in Seattle? 17:44:32 we decided to have intermediate releases 17:44:40 vote? 17:44:48 dtantsur: sure. but "soonish" - I dont know where that came from 17:45:02 my speculations 17:45:02 Vote would be good 17:45:15 voting on? 17:45:19 dates? 17:45:25 devananda: sprint date/location 17:45:33 NobodyCam: 12-14 Aug 17:45:34 not everyone can attend these meetings. 17:45:45 seems odd to be voting on the date 17:45:45 oh. yea. not something to vote on here 17:45:51 to the list! 17:46:21 Okay, then I will [assume] that 12-14 Aug in Seattle is good and move forward 17:46:30 * jlvillal forgets about the mailing list at times. His life is only about IRC.... 17:46:52 quick question for folks re: dates 17:47:00 ok so we'll move on and maybe get thru the whole agenda 17:47:07 waiting 17:47:08 regadless of release models, who would prefer a date sooner than aug 12? 17:47:45 devananda: I am good with +/- a week 17:47:47 mmm, actually. I might be out of town aug 13-16 :/ 17:48:02 I mean like a month earlier 17:48:04 go without me if that's the best date but I'd like to be there if possible 17:48:17 I would prefer anytime after 4-Aug. As I would not be able to attend in July. 17:48:19 devananda: sounds like we need a doodle thing on dates 17:48:26 yea ... sounds like we need a poll 17:49:03 at the summit, there was discussion about trying to colocate with another project (or at least have ironic liaisons at other projects) 17:49:10 #action devananda to post a poll for midcycle dates 17:49:14 then let's do a poll so we can get a consensus that works for as many as possible. 17:49:19 maybe 'discussion' is too strong. more like 'mention' 17:49:46 rloo: +1 for liasions 17:50:14 we'll need a list of where / when the other mid cycles are 17:50:16 we have two topics left, should we agree to poll and move on? 17:50:27 rloo: IIRC, we said colocating with nova might be good, and we should try to cross-pollinate with cinder and neutron 17:50:28 yep moving on :) 17:50:33 ++ to moving on 17:50:41 #topic capabilities 17:50:45 Nisha: are you here 17:50:51 NobodyCam, yeah 17:51:06 (links on agenda item) 17:51:09 i wanted to know the discussion on capabilities 17:51:25 has there been discussion on it? 17:51:28 I haven't see any 17:51:41 even devananda mail on summit update doesnt list any update on it 17:51:51 i heard some discussion did happened at summit 17:52:01 but not sure whats the conslusion 17:52:11 outside of the nova scheduler sessions, I didn't see any discussions at the summit even related to this 17:52:27 we had some discussions about flavors extra_specs that sounded like capabilites. 17:52:41 the discussions I had on it were "when are we doing capabilities" 17:52:45 there was a similar spec proposed by thiagop (i think) for adding a "passthrough" to nova flavors, which got heavily -2'd 17:52:47 from approximately 9001 people 17:52:48 perhaps because of the name 17:53:04 #link https://review.openstack.org/186536 17:53:06 but it is, in principle, trying to achieve the same thing: pass some flavor data down to Ironic so that the driver can act upon it 17:53:09 devananda, ok...so how do we want to deal with capabilities for ironic 17:53:10 gabriel-bezerra: thanks! 17:53:26 devananda: np 17:54:01 devananda, that is done still, correct? 17:54:02 Nisha: so one problem with this work is that Nova is (still....) trying to refactor and split out the scheduler 17:54:03 I'll discuss with johnthetubaguy and dansmith about that later though 17:54:07 There were some discussion about by-pass flavors. Nisha Imentione dyour nova/capability specs at one of the break-out session but I don't think we made any conclusion. 17:54:08 so they are resisting anything which changes how the scheduler works 17:54:46 it's quite frustrating for me as well. BUT. I've proposed to Nova an alternative approach, which is basically that we create a new plugin for the scheduler that queries Ironic's REST API directly 17:54:56 so maybe better to wait until they finish their refactor 17:55:05 * jroll cries 17:55:10 5 minutes 17:55:13 to do that, we need to implement a queriable endpoint, with filtering abilities, and probably do some table refactoring 17:55:15 NobodyCam, that may be too late for us to get anything in Nova 17:55:15 "wait on nova" is always sad 17:55:16 I haven't written this anywhere yet 17:55:20 any idea on when that refactor might happen? earliest is M (my guess) 17:55:20 in liberty 17:55:27 don't count on it :) 17:55:39 I don't think this is completely wrapped up in the scheduler, FWIW 17:55:48 the concerns are more fundamental than that, 17:55:51 so first step is probably for me to write a spec on what dansmith and mikal and I talked about, as far as the API in Ironic and the Nova scheduler changes to use it 17:55:59 which means the "good news" is we can discuss it separate from that I think 17:56:01 I was in the design session about refactoring flavors extra_specs. I can see the intention/the pain point but could not see agreement there. 17:56:18 dansmith: oh? 17:56:18 dansmith: awesome 17:56:55 are we going to have an open discussion before the hour runs out? 17:56:57 we have one more topic on the agenda 17:57:00 dansmith: Ah. Nova's idea of a flavor == find the thing I want, != make the thing I want magically appear 17:57:03 yes? 17:57:28 blah. time. let's open it up and continue this afterwards 17:57:31 #topic Open Discussion / Food For Thought 17:57:41