17:00:35 #startmeeting ironic 17:00:36 Meeting started Mon May 9 17:00:35 2016 UTC and is due to finish in 60 minutes. The chair is jroll. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:37 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:39 The meeting name has been set to 'ironic' 17:00:42 o/ 17:00:43 \o 17:00:45 o/ 17:00:45 o/ 17:00:50 o/ 17:00:50 :-) 17:00:51 o/ 17:00:54 o/ 17:00:54 o/ 17:00:56 as always, agenda is here: 17:00:58 #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting 17:01:04 let's jump in 17:01:06 o/ 17:01:11 #topic announcements and reminders 17:01:15 o/ 17:01:18 o/ 17:01:20 so uh, welcome back from the summit everyone :) 17:01:53 gate was broken this morning 17:02:00 revert just merged in, should be better now 17:02:02 #link https://review.openstack.org/#/c/314024/ 17:02:11 Thanks dtantsur for troubleshooting it :) 17:02:17 o/ 17:02:17 +1 17:02:20 Thank you dtantsur 17:02:31 o/ +1 17:02:44 other than that, most of the team is working hard on upgrade testing, which is our #1 priority right now 17:03:05 I have summit summary coming out soon, only a couple more sessions to write about 17:03:30 and midcycle things - there's a topic on today's agenda for that 17:03:32 any other announcements / reminders? 17:04:00 reminder to update subteam reports :) 17:04:22 and newton priorities were set 17:04:58 ah, yes. newton priorities are here: http://specs.openstack.org/openstack/ironic-specs/priorities/newton-priorities.html 17:05:00 #link http://specs.openstack.org/openstack/ironic-specs/priorities/newton-priorities.html 17:05:38 nothing else? 17:05:50 #topic subteam status reports 17:05:54 as always, those are on the whiteboard 17:05:59 #link https://etherpad.openstack.org/p/IronicWhiteBoard 17:06:02 starts at line 85 17:06:14 I'll give folks a minute to review, and then I think we want to get meta about this for a moment 17:07:13 o/ 17:08:03 jroll: I wonder if we should have said something about your patch to switch to tinyIPA for gate jobs 17:09:07 NobodyCam: maybe, thank you 17:09:11 I'll repeat what I wrote there: I suggest we switch -2 from the portgroups API patch to the network drivers one 17:09:15 NobodyCam: (mine just switched grenade jobs) 17:09:23 Hi 17:09:27 I understand it's nice to land them together, but these are huge patches which are not easy to review 17:09:27 dtantsur: possibly, though it would be nice to land the api changes somewhat together. devananda had a similar opinion 17:09:34 see above :) 17:09:34 dtantsur: I'm curious as to why. the API changes are the hardest to back out after we land 17:09:36 right, so 17:09:48 devananda, do we expect any changes there? it's essentially CRUD 17:10:03 we suggested in this morning's meeting that folks split those patches up 17:10:08 we're artificially delaying landing of the whole thing, hence my concern.. people have to rebase so much code 17:10:16 splitting would be nice yeah 17:10:24 jroll: split up which patches? 17:10:35 no use in splitting if we're going to block the whole chain in the same manner 17:10:36 rloo: networks work 17:10:41 it's basically two 2500 line patches right now 17:10:43 they'll still have to rebase the whole thing every time 17:10:45 pretty hard to review IMO 17:10:54 +1 to "hard to review" though 17:10:57 +1 17:11:00 I've already reviewed the API patch so don't want to split that up. 17:11:01 the other, what, ten patches after that are small enough and easy to review 17:11:12 i've reviewed the network patch and agree, would have been nice to split that up. 17:11:31 I guess I don't have a strong opinion either way on landing the portgroups patch 17:11:33 I am Pramod. i work for opendaylight SDN controller team! i have a question about the bandwidth limit field! Would like to know the maximum and minimum limit which is supported by QOS now 17:11:59 Pramod: this is an ironic project meeting, I think you want #openstack-neutron channel 17:12:05 rloo: when did you review it? I don't see a +2 from you in the last couple months 17:12:08 Pramod, I think you are on the wrong channel, check neutron 17:12:27 devananda: wrt the API? I reviewed it months ago. did it change since then? I assuemd they were all rebases after that. 17:12:46 with or without splitting, I think we can start merging patches not touching drivers 17:13:06 rloo raises a good point: it's hard to track out reviews after rebases... 17:13:15 rloo: I don' tknow if they were all rebases since then or not. it's hard for me to keep track ... 17:13:17 especially on something THAT huge 17:13:34 maybe we should have this discussion later on in the meeting? 17:13:42 lucasagomes: +1 17:13:45 fwiw, i didn't re-review the api changes cuz i assumed they had all been rebases. i was only going to do it ONE LAST TIME... 17:13:46 or in channel 17:13:48 ok fine :) 17:13:52 yeah, sounds off-topic 17:14:03 +1 to in channel 17:14:19 so rloo had some meta-discussion things on this topic 17:14:31 rloo: want to talk about those now? 17:14:44 sure. so i added new subteams to reflect newton priorities. 17:14:53 and live upgrades is no longer a priority. should i remove it. 17:15:01 I think so 17:15:17 ok, #something to removing live upgrades 17:15:17 I guess it's kind of merged into Grenade work 17:15:19 live upgrades is not a priority? 17:15:20 if it's not a priority I think it would be fine to remove 17:15:31 dtantsur: not true. there is code needed for live upgrades 17:15:42 jlvillal: it is not on our list of high priority items 17:15:49 o/ 17:15:49 Ah, okay. 17:15:50 it is a priority, but not a top priority 17:15:56 jlvillal: i believe it was on the secondary list of priorities 17:15:56 got it. then yeah, getting just upgrade tested is a bigger thing to have 17:16:19 so agreed, good to remove live upgrades? any nays? 17:16:50 * jroll pauses 17:17:16 okay, let's do it 17:17:39 done 17:17:51 my next question. i notice that we have some subteams wrt cross project initiatives, oslo & nova. 17:18:08 there are lots of other cross projects https://wiki.openstack.org/wiki/CrossProjectLiaisons 17:18:24 do people think it worthwhile to list those other ones as subteams too? 17:18:38 I personally don't find the existing ones terribly useful, they usually don't have much info 17:18:44 or rather much to report 17:18:58 so do they not have much info cuz people aren't reporting, or cuz nothing to report? 17:19:10 I tend to think the latter 17:19:29 so would a 'cross-project liaisons' be sufficient? (or something like that) 17:19:30 maybe we can make it optional? If there's something to be reported we can freely add to the etherpad for that week 17:19:37 partially because if there's something major, we raise it outside of the meeting 17:19:52 well 'outside the meeting' == ?? irc?? 17:19:54 e.g. api-ref thing, if there was something horribly broken in nova irc pings and emails would happen, etc 17:19:54 maybe a "Other" section where liaisons could put inserting bit should they have any? 17:19:59 rloo, yeah maybe a topic for all seems a good spot 17:20:01 ++ to just "Cross-Project" section 17:20:12 seems like we want to know what might be coming up, not what landed/decided? 17:20:41 sure 17:20:49 eg, i had no idea there was an api-ref for ironic. 17:20:50 dtantsur: ++ 17:21:10 I guess what I'm saying is I haven't personally found valuable info from that section, ever 17:21:27 true. sort of. the oslo ones were informative. 17:21:27 rloo: well, there was an email thread that said "projects should move to this model" 17:21:54 jroll: what i mean was, you moved api-ref to our tree. i didn't even know there was api-ref outside our tree. 17:22:28 rloo: that was a repo the docs team managed for the last several years 17:22:28 rloo: oh, that's because only docs people worked on that. nobody in our project really knew or cared about it. same for most projects 17:22:32 I had no idea either 17:22:33 jroll: even with a doc liaison, we might not have known about the api-ref outside our tree so it might be moot. 17:22:33 it just became cross-project 17:22:38 because the format was super exclusive, etc 17:23:03 anyway, I think a general "cross-project" section is a good middle ground 17:23:24 i'm good with cross-project. anyone against it? 17:23:33 * lucasagomes is fine with it 17:23:51 ++. I think it's very useful for folks who are doing cross-project tracking to raise any upcoming (or recently decided) things to the broader ironic team 17:24:48 that's all I had on this topic, for the time being :) 17:24:56 cool, thanks ruby 17:25:15 anything else from anyone here or can we move on? 17:25:38 #topic proliantutils in our governance 17:25:43 #link https://review.openstack.org/#/c/313667/ 17:25:48 this was brought to my attention today 17:26:11 and I think I'm okay with it, but wanted to see what folks thing 17:26:21 This is wrt vendor CI discussion we had at summit, that CI information is fetched from stackalytics. Using python-dracclient as reference raised two patches for review. 17:26:22 would it be in scope for me to ask what does it mean to be an ironic project and what does it mean wrt responsibilites for ... 17:26:25 stendulker later pointed out that they were just copying what dracclient did 17:26:31 driverlog - https://review.openstack.org/#/c/311277/ and in governance - https://review.openstack.org/#/c/313667/ 17:26:31 does being in our governance means that the core team has to guarantee some quality of that code and things like that? 17:26:39 cause I have no means to test that project 17:26:47 lucasagomes: no, it doesn't 17:26:59 it means the PTL is responsible for the project and its governance, releases, etc 17:27:09 Not sure on the impact of being into governance... 17:27:13 and, as with all things, that can be delegated 17:27:16 it's akin to neutron's "stadium" -- we acknowledge that contributions to that repo are contributions to Ironic 17:27:26 the same model is applied to dracclient, wsmanclient and pyghmi, right? and to some extent to inspector stuff? 17:27:42 yeah seems fine then 17:27:47 so, eg, someone who contributes to proliantutils would be considered an ATC on theIironic project, get to vote on PTL election, etc 17:27:52 dtantsur: yep 17:28:01 dracclient is already in part of the governance so, it makes sense to have the iLO one as well 17:28:04 dtantsur: well, pyghmi isn't in our governance, but otherwise yes 17:28:10 (and potentially others) 17:28:34 jroll, aha. though if we start using vbmc in gate we might want to get more involved in pyghmi 17:28:44 I believe there are other repos like this already under our governance like the Drac 17:28:46 this is the current list of projects we "own" right now: http://governance.openstack.org/reference/projects/ironic.html 17:28:53 dtantsur: yes, I agree :) 17:28:54 not sure I understand the reference to CI and stackalytics, driverlog add isn't an infra requirement 17:29:10 dtantsur, yeah, I've been trying to help with with 17:29:14 I'm really interested on how this is going to work in the grand scheme of things after neutron just kicked all vendor specifc things out of their governance :/ 17:29:23 sambetts: ohh? 17:29:26 so we should be consistent. if dracclient is there, so should proliantutils. 17:29:27 maybe I missed that 17:29:32 krtaylor: right, separate topic, but we did say they should do that 17:29:37 devananda: heh. yeah, it's a thing. 17:29:53 oh. let's follow neutron then. 17:29:55 sambetts: devananda: the krux there was that they were approaching hundreds of projects, afaik, with more coming. 17:30:13 i hope ironic will have hundreds of projects one day too :) 17:30:16 no, let's not blindly follow neutron. but we should consider their reasoning etc 17:30:23 * jlvillal feels like they shouldn't be there. Mostly gut feeling 17:30:46 I think my proposal for now is that we should accept proliantutils for consistency, and if we feel like this is all unmanageable, talk about that at another time 17:30:46 jroll, should we require test teams to add their test system to driverlog? 17:30:57 sambetts: ooh. I see! No vendor drivers here: http://governance.openstack.org/reference/projects/neutron.html 17:31:04 i personally am not comfortable with the hw-specific ones being there. and/or is there a tag we can use to differentiate those. 17:31:14 * sambetts is trying to find their spec for it 17:31:20 krtaylor: well, we wanted to keep marketplace up to date, which is fed by driverlog yes? 17:31:40 jroll, right, good point, then yes 17:31:46 so, I don't want to take the whole meeting on this 17:31:54 but I see there are concerns with too many vendor things 17:32:03 rloo, I suspect there might be limitations like "non-official projects can't do XXX" like with stackforge... 17:32:16 thus people try to get into an official project tent 17:32:21 https://etherpad.openstack.org/p/newton-neutron-community-stadium-evolution 17:32:21 krtaylor: governance inclusion in Ironic shouldn't affect driverlog or third-party CI, AIUI. but it does affect ATC status and contribution metrics on stackalytics 17:32:26 dtantsur: oh. hmm. 17:32:39 i would like someone to talk to neutron folks, think about this, and report back next meeting. 17:32:59 pros/cons. if what dtantur said is true. what are neutron vendors going to do. 17:33:07 can we at least tag them? 17:33:07 sure 17:33:07 yea. to be clear -- if we include the hw driver projects in ironic's governance, then folks who contribute ONLY to those projects (and not to openstack/ironic, our client, etc) will get ATC status and vote in Ironic's PTL election 17:33:12 and that's a long conversation to have 17:33:16 and lots of things to think about 17:33:22 ++ to thinking about this more 17:33:26 and is on the order of months/years, not a week 17:33:42 so yes, we should continue this conversation 17:33:44 so we shouldn't have let any in, in the first place. sigh. 17:34:04 if this is going to take more than a week, then we should let proliant in. 17:34:08 for NOW... I do not want to wait to decide on proliantutils 17:34:15 right, should we let them in or not, today 17:34:17 well, cheating in a PTL election is not hard 17:34:20 I vote yes for consistency sake 17:34:34 ++ for yes 17:34:42 yes (unfortunately) 17:34:44 +1 for in, since we already have other vendors 17:34:45 We have already let some in 17:34:50 so Yes 17:34:51 does anyone vehemently disagree? 17:35:02 For more context on the neutron stuff https://review.openstack.org/#/c/312199/9/specs/newton/neutron-stadium.rst 17:35:10 +1 for consistency today, and +1 for continuing the discussion more broadly 17:35:15 (counting 6 yes 0 no so far) 17:35:20 i assume the caveat would be if that vendor doesn't have CI, their packages are OUT 17:35:44 rloo: another interesting debate to have there :) 17:35:53 this is a possibility 17:36:06 +1, we agreed, maybe informally, that new driver additions would require CI 17:36:29 it was pretty formal :) 17:36:51 okay, I'm going to ack that patch then. thanks y'all. 17:36:53 yea, we have a pretty clear agreement at this point: for a driver to be in ironic's tree, it needs CI 17:36:59 * krtaylor need to make sure that was in the spec 17:37:00 looking forward to someone raising the larger discussion 17:37:17 but that didn't discuss the inclusion of hw-specific libraries in our project governance 17:37:23 yep. 17:38:25 ok, moving on for now 17:38:28 * sambetts has been through this nightmare with networking-cisco (our neutron drivers) and can say its not very fun 17:38:44 hence I've left cisco-ironic-contrib out of the goverence 17:38:58 #topic midcycle! 17:39:08 so I've spoken privately with a few people on this 17:39:29 I think our virtual midcycle went very well last round 17:39:44 but we need to decide whether that should be virtual or physical this year 17:39:53 some folks have offered space if we do a physical midcycle 17:40:23 the pros of a physical midcycle are higher-bandwidth comms, more networking opportunities, we get to see each other's beautiful faces 17:40:50 I would like to have a physical midcycle for all the reasons jroll just listed 17:40:52 pros of a virtual midcycle are that generally more folks can attend (though some may be left out of virtual due to time zones) 17:40:55 if physical, is it in the US? 17:41:15 can we look at a hybrid type midcycle? 17:41:17 rloo: likely 17:41:29 +1 hybrid 17:41:29 * mgould thought the virtual midcycle went very well 17:41:32 * dtantsur as usual votes for a virtual one 17:41:39 +1 to virtual 17:41:48 also I'd be unlikely to be able to attend a physical one in the US 17:41:52 IME a room full of people talking over voice to a single person is terrible experience for the single person 17:41:56 does time frame matter? 17:41:57 so -1 to hybrid 17:41:59 -1000 to virtual 17:41:59 +2 to virtual, +1 to hybrid :-) 17:42:02 * sambetts would also like to see multiple intercycle virtual meetings 17:42:03 I would like to have a f2f midcycle this time, as well as regular virtual meetings (eg monthly, or something) 17:42:10 * jlvillal personally likes physical ones. But he likely can't attend this time as he has vacation plans :( 17:42:13 -1 to hybrid, for the reason jroll mentioned 17:42:20 +1 for regular virtual meetings 17:42:30 jroll, by "hybrid" I was thinking "some sessions are physical, others are virtual" 17:42:30 rloo: elaborate? 17:42:34 +1 virtual, frees up travel budget for summit 17:42:37 the cinder midcycle was hybrid, wasn't it 17:42:40 I don't know if that could be made to work 17:42:43 it's depends on the location for me (and most ppl I guess) 17:42:44 +1 virtual meetings -1 virtual mid-cycles 17:42:51 jroll: have you talked with the Nova team about colocating? 17:42:54 rloo: the cinder midcycle was physical, virtual was read only 17:42:57 jroll: I mean, folks prefer virtual/physical regardless of when it might be held? 17:42:58 +1 virtual 17:43:04 perhaps there should be a vote on the ML about this 17:43:07 devananda: I have not 17:43:11 jroll: there was utube video of cinder midcycle 17:43:24 rloo: right, but folks not in the room could not participate 17:43:26 jroll: the one that TheJulia was in. 17:43:32 * mgould is wondering if the voting is breaking down purely on geographical lines 17:43:34 many who would be affected by a TZ difference with a virtual midcycle or who may be traveling internationally might not be in this meeting 17:43:35 jroll: OH. 17:43:37 to be clear I'm taking this to the mailing list after the meeting 17:43:50 NAians want physical, rest-of-worldians want virtual... 17:43:56 but wanted to get initial feedback 17:44:08 +1 for virtual just to wreck mgould's stats. 17:44:12 mgould: in my experience, it was never perfectly along those lines 17:44:17 rloo, hah :-) 17:44:17 :) 17:44:52 +1 physical midcycle, +1 virtual meetings on a regular basis 17:44:54 oops late :P 17:44:56 my personal vote is also for virtual, because there are people that I really wish were present, that won't or can't attend a physical midcycle 17:44:58 having been NA and !NA, i would still vote for physical midcycle even if i had to travel (pending funding) 17:45:39 I would rather be able to participate, even at a lower bandwidth, that not be able to go due to travel budget 17:45:41 * sambetts doesn't see much gained for a 8+ hour flight over a virtual midcycle 17:45:54 ++ 17:46:13 yeah, oversees flight with its prices just for 2-3 days... I won't even remember you all due to jet lag :D 17:46:30 I'd be down to try a virtual meetup, considering I wasn't part of the last one and heard it went well 17:46:45 dtantsur, sambetts: arguing at a white board and then drinking together afterwards :) 17:47:10 EU could have a midcycle at the same time ;) 17:47:23 right, so "beer at night" is the primary reason for physical that I hear these days 17:47:31 if we go virtual it might be good to have a screen share of some kind 17:47:35 and I don't think that's valuable enough to artificially exclude half of our cores 17:47:51 (half is a straw man number to be clear) 17:47:59 also note that it's likely that both design summits the next year will be in NA ;) 17:48:14 so s/half/a significant portion/ 17:48:41 IMHO, physical is less open, favors participants that have deep travel budgets 17:49:04 i'm more of a visual person so sometimes i get a bit lost in the audio-only stuff 17:49:06 * mgould can drink beer during the virtual sessions, if it would help... 17:49:16 lol 17:49:24 krtaylor, +1 (mgould +1 there too) 17:49:27 mgould: that most certainly happened last cycle :) 17:49:29 mgould: lol 17:49:49 I'm going to open up discussion in case folks have other topics, feel free to continue this one as well. I'll send an email to the list later today. 17:49:50 cinerama: i agree about the visual aspect being important; i was wondering if there's a video service where we could hold enough people 17:49:53 #topic open discussion 17:49:55 i also think that strengthening relationships between folks is an important thing that comes out of summit and midcycles, even if that doesn't directly map to a technical goal 17:50:02 mariojv: not with free software :( 17:50:21 mgould, I was drinking whiskey the last time :) 17:50:25 mariojv, we looked into this and couldn't find a solution that was both scalable enough and open-source :-( 17:50:32 dtantsur, me too :-) 17:50:34 i see, that's unfortunate. 17:50:47 hangouts works for break out sessions up to a point 17:52:07 jroll: one other thing to consider, the proposed changes to summit and introduction of the new "PTG" event may replace midcycles in a year 17:52:27 nothing for Open Discussion? 17:52:37 are we looking at July for the midcycle? 17:52:54 sambetts, yeah, I think that if we need to use video (to share screen or something like that) we can get a group of people that is working on specific problem and start a hangout to deal with it 17:53:42 devananda: yep 17:53:53 rloo: likely, maybe early august. we didn't get to the "when" :) 17:54:11 lucasagomes: most of the collaboration tools like that are proprietary / platform-specific 17:54:32 jroll: ok. early aug is out for me so my vote wouldn't count if it was for then. 17:54:46 devananda: lucasagomes: which is okay if it's a focused group of folks that all accept that. just not ok for the main event 17:54:52 devananda, yeah. But I was thinking about having a video chat (if needed) only with a sub group of the people working on a specific problem 17:54:55 lucasagomes: this is one of the big challenges with a virtual midcycle: we have folks on so many different platforms, some with high network latency 17:54:56 say people working on grenade 17:55:17 jroll, yes, not for the main event 17:55:41 well can talk about it on the ML 17:55:49 some folks may be excluded due to technology, if the chosen communication medium is not open 17:55:59 even if they want to join that subgroup 17:56:08 bluejeans is web based no? 17:56:11 there's no perfect answer 17:56:38 NobodyCam, it requires a plugin 17:56:39 devananda, +1 for the concerns 17:56:44 tl;dr if we choose a technology, it needs to be stallman-compatible and low-bandwidth, else someone gets excluded 17:56:45 :( 17:56:56 jroll: exactly 17:56:59 lucasagomes: Does Red Hat have an approved video conference system? 17:57:15 Since they tend to be the most open source pure. 17:57:26 jlvillal, nop :-( we use bluejeans 17:57:26 jlvillal: blue jeans 17:57:31 k 17:57:32 asterisk can do it but our install needs an upgrade? 17:57:37 sigh. so if it is physical, folks will be excluded. if it is virtual, we want low-bandwidth so people aren't excluded. 17:57:47 if people are interested pabelanger can probably provide more infos 17:57:54 and either way, folks in different time zones are/maybe excluded. 17:58:03 *Two* Minutes 17:58:10 who really wants to be in the mid-cycle? :) 17:58:12 clarkb: I would love more info 17:58:20 Can't believe in 2016 we dont have anything to host 50 participants and a video stream 17:59:01 computers are the worst 17:59:04 :) 17:59:07 rloo: I want to assist, physical or virtual 17:59:15 one minute left, shall we? 17:59:27 ++ thank you all great meeting 17:59:40 #endmeeting