17:00:06 #startmeeting Ironic 17:00:07 #chair devananda 17:00:07 Welcome everyone to the Ironic meeting. 17:00:08 Meeting started Mon Apr 20 17:00:06 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:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:12 The meeting name has been set to 'ironic' 17:00:12 o/ 17:00:13 Current chairs: NobodyCam devananda 17:00:20 Of course the agenda can be found at: 17:00:20 #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting 17:00:24 o/ 17:00:32 #topic Greetings, roll-call and announcements 17:00:32 Roll-call: Who's here for the Ironic Meeting? 17:00:42 howdy all 17:00:42 o/ 17:00:42 me 17:00:44 o/ 17:00:45 o/ 17:00:56 o/ 17:00:58 o/ 17:01:05 o/ 17:01:19 o/ 17:01:25 great to see you all :) 17:01:30 hiya folks 17:01:49 looks like one one Announcement 17:02:02 Big Thank you to Lucas and Chris Dent for picking up WSME 17:02:08 as core members 17:02:20 for more info see the link on the agenda 17:02:44 \o 17:02:51 * BadCub applauds 17:03:19 any other Announcements 17:03:23 while its awesome that we can breathe a litlte life into WSME to fix bugs 17:03:42 p/ 17:03:55 I'd like us to also begin thinking about moving off of WSME soon, as the project isn't maintained by anyone else, and I dont think there's benefit (long term) in us taking that on 17:04:05 something to discuss at the summit, perhaps :) 17:04:07 devananda: I think I know where your going I also have a item under open discussion sectiom 17:04:17 cdent being on it means ceilometer will probably continue to work on it no? 17:04:44 just noting that here so that the announcement doesn't look like we're taking it on long-term 17:05:32 ahh 17:05:34 :) 17:06:07 ok then we can move on to : 17:06:16 #topic SubTeam: status report 17:06:44 white board seems like only few sections are updated 17:06:57 #link https://etherpad.openstack.org/p/IronicWhiteBoard 17:07:27 I don't really expect a ton of updates this week 17:07:41 no news is good news :) 17:07:45 :) ya .. :) 17:08:02 * devananda notes that stackforge doesn't have any info for driverlog + ironic + kilo -- http://stackalytics.com/report/driverlog?project_id=openstack%2Fironic 17:08:04 :) 17:08:15 dtantsur: posted bug numbers https://etherpad.openstack.org/p/IronicWhiteBoard 17:08:24 do we want to mention what is kilo-rc-potential material? 17:08:40 rloo: +1 17:09:13 rloo: yes, i was just looking at that. 17:09:14 hm, I don't see kilo-rc-potential tag 17:09:23 #link https://bugs.launchpad.net/ironic/+bugs?field.tag=kilo-rc-potential 17:09:28 it's not official, so it's not in the list 17:09:41 dtantsur: what's not official? 17:09:46 * devananda adds it to official bug list 17:09:47 the tag 17:10:04 rloo, launchpad has notion of "official" tags for a project 17:10:09 dtantsur: oh. guess it'll be official very soon. thx ;) 17:10:21 so currentlly only one open bug 17:10:28 well 17:10:41 the "fix committed" bug still has the kilo backport patch open 17:10:55 ttx has a -2 on it, I guess the RC window isn't open yet or something? 17:11:03 ahh 17:11:11 https://review.openstack.org/#/c/174122/ fwiw 17:11:14 so if someone thinks/wants something to go to kilo, they tag it, and we approve (or not) the patch, and then ttx has final approval? 17:11:15 correct -- the rc2 window isn't open yet 17:11:24 #link https://review.openstack.org/#/c/174122 17:11:46 process is outlined on the wiki page for stable branches, though it was just changed slightly last week (see emails from dhellmann and ttx) 17:12:10 JoshNang: do we have a server patch for https://bugs.launchpad.net/ironic/+bug/1441445 ? 17:12:12 Launchpad bug 1441445 in Ironic "As per the state machine, ironic doesn't provide an option to move from CLEANFAIL to CLEAN" [High,Triaged] 17:12:23 or am I thinking of a rescue mode thing 17:12:42 tldr; file bug, tag with kilo-rc-potential (or kilo-backport-potential after the release), propose fix to master. fix must be merged in master. cherry-pick -x the commit back to stable/kilo and propose that. 17:12:55 jroll: that was rescue 17:12:58 k 17:13:08 the wiki page for stable branches: https://wiki.openstack.org/wiki/StableBranch 17:13:25 then ttx and I decide if and when to merge it, based on release cycle, severity of bug, risk of the change, etc 17:13:33 # link https://wiki.openstack.org/wiki/StableBranch 17:13:48 thx devananda 17:13:49 note that we also have a stable branch for the client now, too 17:14:08 devananda: oh yeah. the client. was that branch cut on a package release? 17:14:09 iow, we need to follow the same process there, which it looks like dtantsur has done for the retry patch 17:14:13 rloo: yes 17:14:49 0.5.x will be consisered stable/kilo series, and 0.6.x (not yet tagged) is what we'll develop on going forward 17:15:16 why not starting giving client names like "Kilo" and versions like 2014.1? :) 17:15:27 looks like they follow usual openstack process now 17:15:37 well, not exactly 17:15:42 we can still tag clients any time 17:16:18 right 17:16:39 there seem to be some more changes happening around this stable branches of libraries and clients thing 17:16:50 like not having a proposed/kilo branch any more 17:17:18 anyway, we've got 2 bugs right now tagged for backport potential 17:17:31 any others that folks want to bring up? 17:17:33 devananda: is there info we can review on the changes forthcomming? 17:17:55 NobodyCam: aside from reading the mailing list, not that I know of. 17:18:02 ack :) 17:18:19 i'm still digesting it, which is partly why I haven't done an announce of how it affects us yet 17:18:37 oh we should prob change the topic 17:18:47 #topic Open Discussion 17:19:00 as that is the only place we have items on the agenda 17:19:25 devananda: :) ahh Thank you 17:20:14 rloo: your up 1st with utf-8 encoding 17:20:42 so this bug/patch has been around for awhile. I'm into 'spring-cleaning' mode. wanted to 'get rid of it'. 17:20:48 https://bugs.launchpad.net/ironic/+bug/1325193 17:20:49 Launchpad bug 1325193 in python-ironicclient "Some Python files do not specify the file encoding" [Low,In progress] - Assigned to Martin Geisler (mgeisler) 17:20:59 patch: https://review.openstack.org/#/c/97027/ 17:21:16 the patch basically adds a utf-8 coding line to every file. 17:21:54 I discussed it briefly with lucas, and he would like that line added, because it will help eg Asian folks. 17:22:19 Anyone against adding it? 17:22:54 rloo: Why doesn't it use: # coding=utf-8 ? 17:23:21 why should it? :) 17:23:26 rloo: But no opposition here 17:23:40 I have no issues 17:23:46 dtantsur: Well it is using the emacs version ;) 17:23:47 IIRC this form was chosen as both Emacs and Vim understand it 17:23:47 jlvillal: that's what it is proposing, to add coding: utf-8.? 17:23:51 no opposition 17:24:04 jlvillal: oh, that's what you meant. guess dtantsur answered :) 17:24:49 dtantsur: If it works for both, it works for me :) 17:24:55 ok, so can we do some #agree thingy saying it is OK, and I'll get in touch with Martin to see if he wants to finish it. 17:25:02 rloo: my only opposition to this is that it's adding cruft that humans shouldn't have to maintain.. we're going to add files and forget to add this header to them 17:25:17 rloo: it should be an editor setting, not a hint in every single file 17:25:30 the opposite is valid too: people will add files with this line :) 17:25:39 devananda: just like the other cruft we have. I'm fine not putting it in either. We already have some files with it. 17:25:50 can we add a hacking check for it? 17:25:56 look at other projects -- I do not see this in every single file in nova, swift, keystone, .. 17:25:58 just enforce its there? 17:26:38 I think there are lots of other things we should be spending time on deciding. I just wanted to 'do something' and be done with it. Note that the client files have it. (or had it; maybe some new ones don't now!) 17:27:02 I understand the reason: some developers don't have their project (or their editor) configured in the same way that I do 17:27:10 I agree that it should be done via hacking, whichever way we prefer 17:27:14 but those developers are asking the project to assume responsibility to tell their editor what to do 17:27:25 and i don't think it's the project's responsibility to carry the hint in every single file 17:27:39 devananda: +1 I agree 17:27:45 and then add a hacking rule to reject code that doesnt include a # -*- coding: utf8 -*- line 17:27:47 devananda: +1 17:27:52 I think it is only needed if there is non-ASCII code in the file. From my reading. Which should then fail the gate, which would be a hint to add it. 17:27:57 isn't this also a signal to python? 17:28:06 jroll: Yes 17:28:10 to parse the file as utf-8, not ascii 17:28:13 right, ok 17:28:15 https://www.python.org/dev/peps/pep-0263/ 17:28:27 right. so if we HAVE non-ascii chars in a file, we should clearly add this hint for python 17:29:14 but i still object to seeing it in every single file 17:29:16 Martin's choice " c) Remove the lines where they aren't strictly needed (Python requires the line if the file has non-ASCII characters)." 17:29:30 so, let's vote 17:29:32 so I take this as add to a file if its needed 17:29:32 but I don't think we want to enforce that *only* the files that need it, should have it. 17:29:50 NobodyCam: I think if a file needs it, it should already be there. 17:30:31 tbh I'm not sure we should have files with non-ASCII 17:30:36 ugh. /me llooks up how to run a vote 17:31:12 python 3 defaults to utf-8 too 17:31:12 * jroll votes for apathy 17:31:21 #startvote should ironic require all files to have an encoding hint? Yes, No, Only, Abstain 17:31:21 Begin voting on: should ironic require all files to have an encoding hint? Valid vote options are Yes, No, Only, Abstain. 17:31:22 Vote using '#vote OPTION'. Only your last vote counts. 17:31:31 "only" = only when needed by python 17:31:43 well. that's redundant. 17:31:45 #undo 17:31:46 Removing item from minutes: 17:31:54 #startvote should ironic require all files to have an encoding hint? Yes, No, Abstain 17:31:55 Already voting on 'should ironic require all files to have an encoding hint' 17:32:00 bah 17:32:13 * rloo thinks we don't vote enough ;) 17:32:17 #endvote 17:32:18 Voted on "should ironic require all files to have an encoding hint?" Results are 17:32:24 #startvote should ironic require all files to have an encoding hint? Yes, No, Abstain 17:32:24 Begin voting on: should ironic require all files to have an encoding hint? Valid vote options are Yes, No, Abstain. 17:32:25 Vote using '#vote OPTION'. Only your last vote counts. 17:32:25 looks like #undo worked for the last link 17:32:32 dtantsur: yea :( 17:32:37 #vote no 17:32:54 #vote no 17:32:55 #vote No 17:32:56 #vote no 17:32:57 #vote yes (on lucas' behalf) 17:32:58 rloo: yes (on lucas' behalf) is not a valid option. Valid options are Yes, No, Abstain. 17:33:04 lol 17:33:07 #vote yes 17:33:11 #vote no 17:33:16 #vote no 17:33:17 #vote no 17:33:24 #vote no 17:33:25 #vote no 17:33:37 #vote no 17:33:49 #vote no 17:34:01 will give it another 30 seconds 17:34:06 #vote abstain 17:34:07 #vote no 17:34:18 I do under stand lucas' point, but agree with devananda it should n't required for every file 17:34:25 the change needs a better story, IMO 17:34:51 #endvote 17:34:52 Voted on "should ironic require all files to have an encoding hint?" Results are 17:34:53 Yes (1): rloo 17:34:54 Abstain (1): jroll 17:34:55 No (12): TheJulia, NobodyCam, pshige, jlvillal, BadCub, devananda, JayF, JoshNang, dtantsur, Shrews, natorious, vdrok 17:35:15 sweet. thx everyone! 17:35:16 the no's have it 17:35:20 rloo: cheers. there you go :) 17:35:49 ok to move on. 17:35:57 I'd like to take a little collective time to look at the ideas we've got for the summit 17:36:20 :) 17:36:20 devananda: +1 17:36:24 we have about 3 weeks to organize them, which'll go pretty fast 17:36:38 before we move on, dare I ask if we should remove the encoding hints from ironicclient now? 17:36:43 #link https://etherpad.openstack.org/p/liberty-ironic-design-summit-ideas 17:36:58 jroll: heh. I'd +2 that patch, fwiw 17:37:02 :) 17:37:08 but also don't care /that/ much 17:37:16 ++ 17:38:06 jroll: being a consistency freak, I'll remove them :) 17:38:31 heh, thanks rloo :) 17:38:47 we've got 3 types of sessions, so I think i'll start (after the meeting) reorganizing this 'pad based on that 17:39:04 lots of good topics on the etherpad 17:39:13 devananda: do/should we have a deadline for taking suggestions? 17:39:16 2 big room slots, which is more a place to gather feedback from the community 17:39:50 several fishbowl / small room things to sort stuff out ourselves 17:39:56 and then a full day friday to do what ever we need to 17:40:19 also, if anyone is proposing sessions with other service teams,w e should cross-link from this pad 17:41:22 devananda: do have sessions inmind for the larger "big room " slots 17:41:54 rloo: it'd help me out if all the suggestions are in by May 7 at the latest 17:42:21 I'd love to bring up third party testing requirments in fromt of a large group but I also it it easly going sideways 17:42:48 devananda: so after you reorg the etherpad, maybe add a section/area for new suggestions? 17:42:49 s/it it/see it/ 17:42:54 NobodyCam: yah. I think 3rd party CI is a thing we need to start being more explicit about, but I dont think a whole session on that is going to produce anything 17:43:09 rloo: ++ 17:43:21 devananda: ya 17:43:58 things that might need a big room, on my mind ... 17:44:06 - networking stuff 17:44:10 is there an operator's track where we might get feedback for ironic. last summit, I don't recall much feedback at all. 17:44:13 - general ops feedback 17:44:19 would love smaller group session on : Driver composition matrix 17:44:21 rloo: there is an ops track. we should propose sessions there 17:44:39 NobodyCam: +1 for small group session for the driver matrix 17:46:16 #link https://wiki.openstack.org/wiki/Design_Summit/Planning 17:46:26 all the projects' etherpads for proposing things are there ^ 17:46:27 any reason to cover any of the micro version stuff in the big rooms? (i thinking no but want to hear others thoughts) 17:47:13 NobodyCam: don't think so, but we might want to discuss 'finishing' it, maybe on Friday? 17:47:30 NobodyCam: and/or talk to Nova folks to see how it is working for them :) 17:47:53 I think we need to have two conversations with nova this cycle 17:48:16 NobodyCam: unless one of the big room sessions is to discuss what is new in kilo. 17:48:17 one around how they will continue handling federated / clustered hypervisors 17:48:36 another for the networking issues around assuming that we have only one network per port 17:48:46 does anyone want to take the lead on either of those? 17:49:02 devananda: maybe also some chatting on the topic of testing? 17:49:08 I definitely do not want the lead on the former :P 17:49:31 I could take the latter if necessary, though I'm not sure the best way to fix it 17:49:42 * rloo guesses that non-ironic folks will be asking about federated/clustered hypervisors 17:50:00 NobodyCam: keeping everyone on the same page about testing is good. maybe a slot in our meetup on friday? 17:50:11 oh ++ 17:50:12 rloo: nova folks are, by and large, quite familiar with the problem space by now 17:50:23 rloo: they seem to differ in how they want to address it, though 17:50:40 jroll: if you can, that'd be great 17:50:41 devananda: yeah, so they need to go into a small room and duke it out :) 17:50:44 so really this is about getting them all in a room and making them figure it out :P 17:51:02 #link https://etherpad.openstack.org/p/liberty-neutron-summit-topics 17:51:09 devananda: I guess what does 'take the lead' entail here? I'm not sure I want to run that session, but I can try to make sure it happens 17:51:09 #link https://etherpad.openstack.org/p/liberty-nova-summit-ideas 17:51:25 * fyi Nine minutes * 17:51:28 jroll: where 'them' includes some of us 17:51:35 right 17:53:22 is it on purpose that people put suggestions in etherpad w/o their names? 17:53:53 rloo: harder to read with names every 20 chars? 17:54:11 rloo: but seriously, if someone wants to run a session, they should put their name up, otherwise I'm going to run them all :P 17:54:33 devananda: sometimes I wonder/want more details, can't ping someone if you don't know who they are. 17:54:59 * rloo is fine with devananda running all the sessions :) 17:55:15 devananda: Here's the question: Do you want the person running the session to have an opinion on it? 17:55:26 honestly, rather than proposals by a single person // pushing a single new feature, we should really be discussing things that most (if not all) of us are already familiar with 17:55:34 rloo: if users set their name the solor will tell you who it was 17:55:36 devananda: I'd think an 'impartial moderator' could be more interesting in some of these formats 17:55:38 feature proposals should be going through the spec process 17:56:04 JayF: I'm hardly impartial, but I am happy to moderate :) 17:56:04 s/solor/color/ 17:56:05 devananda: but eg the state machine stuff got somewhat hashed out at the last summit. 17:56:43 rloo: right. that's a great example of the sort of high bandwodth collaboration I'd like to see more of htis time 17:56:47 devananda: although I guess it was something that more than one person was interested in. 17:57:13 devananda: well I'm saying generally I'm willing to take that role in sessions as needed; 17:57:22 JayF: awesome, thanks. 17:57:47 * rloo wonders when JayF has ever been impartial, but am happy to have JayF do it too :-) 17:57:57 lol 17:58:01 rloo: I usually only talk when I have an opinion on things :) 17:58:09 * Two Minutes Left * 17:58:09 rloo: something like functional testing ... my only opinion is that we do it :D 17:58:42 JayF: opinions are good ;) 17:59:10 by the way, I did want to mention/confirm. we are NOT supporting nova baremetal migration outside of juno, right? 17:59:18 rloo: correct 17:59:27 that code was dropped from nova already anyway 17:59:42 devananda: right, but we forgot to drop the migration code from ironic/kilo. 17:59:43 and we're not supporting a migration that skips a release at this time 17:59:49 rloo: ugh 18:00:02 devananda: i have a patch for L*, you want that backported to kilo? 18:00:07 * beep * thats time 18:00:09 rloo: wait that's right. it should be in kilo, not in liberty 18:00:12 anyway, thanks all 18:00:18 i'll clean up this pad before next week 18:00:19 thank you all 18:00:21 thanks 18:00:24 hopefully some of you want to help add more things :) 18:00:26 cheers! 18:00:27 thanks 18:00:32 #endmeeting