19:00:05 #startmeeting Ironic 19:00:06 o/ 19:00:06 Meeting started Mon Oct 6 19:00:05 2014 UTC and is due to finish in 60 minutes. The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:09 The meeting name has been set to 'ironic' 19:00:13 o/ 19:00:20 as usual, our agenda is on the wiki 19:00:22 #link https://wiki.openstack.org/wiki/Meetings/Ironic 19:00:33 #topic announcements 19:00:47 probably something everyone is aware of, but we tagged RC1 last week :) 19:01:02 :) w00 h00 19:01:03 cheers for all the work fixing bugs lately, folks! 19:01:08 great! 19:01:37 so, until the final release is tagged on Oct 16th, please test it 19:02:03 o/ 19:02:14 and if you find bugs that are still release critical, please tag them in LP with "juno-rc-potential" 19:02:32 after Oct 16th, the tag will become "juno-backport-potential" 19:03:17 also, Kilo is now open for specs 19:03:27 I posted a few changes to the spec template and its unit tests last week 19:03:52 :) and the reviews are already underway. very good job to all :) 19:04:02 that's the only release announcement from me. I'll save the discussions of summit for the next topics 19:04:24 NobodyCam, lucasagomes: any other annoncements? 19:04:37 you covered what I had 19:04:43 :) 19:04:46 yeah I think we are good 19:04:52 can't think about anything else 19:04:55 #topic Juno status 19:05:03 actually I think I just covered this section ... moving on ... 19:05:07 #topic Kilo planning 19:05:20 ok! Kilo! so, specs are open :) 19:05:37 let's talk a bit about the summit as we now have more details on the scheduling 19:05:56 would love more eyes on https://review.openstack.org/#/c/126019/ 19:06:02 we've got 4 design slots on wed. morning and 1 on thurs. afternoon 19:06:03 someone has a link handy to the scheduling? 19:06:14 http://kilodesignsummit.sched.org/ 19:06:18 #link http://kilodesignsummit.sched.org/ 19:06:21 cheers 19:06:25 #link http://openstacksummitnovember2014paris.sched.org/event/722245d15f368a720d95c9a9bbb77100#.VDLALHWx15Q 19:06:51 and 19:06:52 #link http://openstacksummitnovember2014paris.sched.org/event/10c3a654c250f60b9efc7f18cd7d2cb8#.VDLoSHWx15Q 19:07:07 ouch yeah it conflicts with JayF talks :/ 19:07:09 I've asked the organizers to bump JayF's talk so it won't conflict with our sessions 19:07:23 the reschedule tentatively looks good, but not confirmed yet 19:08:24 we also have a slot in the Operator track on Monday, which isn't shown yet on the schedule 19:08:50 and a half-day meetup Friday afternoon (again, not shown yet) 19:08:53 so 19:09:15 I'd like to organize our discussions around that 19:09:35 getting operator input Monday, cross project and conference things Tuesday, then most of our sessions on Wednesday 19:09:43 and specifically for those things we need to build concensus on 19:09:52 like exposing hardware capabilities 19:10:00 what is Friday's 'contributors' meetup meant for? 19:10:25 rloo: unconference space specifically scheduled for Ironic. we get a room for 3.5hr 19:10:40 devananda: thx. a free-for-all then (just joking) 19:10:41 we also (like all projects) have a "pod" where we can have unscheduled things 19:10:43 read: we all argue about things :) 19:10:54 we could just sit together and hack on code 19:11:12 or have tea :) 19:11:23 deva, what ironic related topics/event onTuesday afternoon? 19:11:26 and croissants 19:11:29 sounds like a sample of a mid-cycle :) 19:11:56 wanyen: tuesday there is a talk by jroll in the main conference track (I linked it above) 19:12:02 wanyen: our design sessions are on wednesday 19:12:24 okay. Ihave a brownbag talk on Tuesday afternoon as well 19:12:34 wanyen: have a link? 19:12:46 I nned to find it. hold on 19:13:00 any questions / thoughts / comments on the summit -- let's start discussing it 19:13:08 devananda: will there be details later wrt what the tues cross-project workshops are? 19:13:21 fwiw, for the next two meetings, I expect this to take up a decent chunk of our time 19:13:54 rloo: eventually yes. but those might not be set until just a week before the summit 19:14:27 should we add a voting coloum to the spread sheet as to what items we want for out sessions? 19:14:32 oh, as a reminder, here's a link to our planning doc 19:14:32 jroll: I don't have a link. it's ILo driver talk at 2:30 pm on Tuesday 19:14:33 #link https://docs.google.com/spreadsheets/d/1XBKdeDeGfaRYaThjIIoYRwe_zPensECnxsKUuqdoVmQ/edit#gid=0 19:14:36 right, so we have 4 slots and lot of items in the spreedsheet 19:14:38 #link https://docs.google.com/spreadsheets/d/1XBKdeDeGfaRYaThjIIoYRwe_zPensECnxsKUuqdoVmQ/edit#gid=0 19:14:44 we should start voting on them maybe? 19:14:53 lucasagomes: 5 slots. 4 are wed. 1 is thurs. (the split is odd...) 19:15:00 oh yeah my bad 5 19:15:03 I might have forgotten to say that 19:15:28 so vote for your top 8 and we'll take the top 5 19:15:30 ??? 19:15:47 vote by adding your name in the "interested" section 19:15:53 and keep adding ideas, too 19:15:58 right 19:15:59 I plan to enter a few items to the spreadsheet 19:16:04 maybe we should merge some of the talks too 19:16:16 we did it last summit, if we think that it's small or the topic are related 19:16:33 wanyen: please do soon as we are asking folks to vote on items 19:16:37 we don't need to settle the schedule until Oct 27, though I'd like to finish it by Oct 25 19:16:54 heh, if putting your name in interested is voting 19:16:56 then I need to unvote 19:16:58 when will we start vote on the topics? 19:17:20 now? 19:17:34 dumb question. what is the purpose of the 'design' sessions? I don't recall much design stuff from previous summits. 19:17:37 yea there are already names in the interested col 19:17:51 rloo: right. well. we should be designing things in those meetings 19:17:55 I will enter my topics tonight 19:18:17 for example, at the midcycle we discusssed how we might expose hardware / driver capabilities or properties in a generic way 19:18:29 such that Nova flavors could be used to just-in-time reconfigure hardware 19:18:31 so we vote on things/features that we know we need/want in ironic, and we discuss the design of those features at the summit? 19:18:38 JayF and I have some similar thoughts on this 19:19:00 but I dont think it's been widely discussed 19:19:08 so the summit might be a good time to discuss that large of a change 19:19:09 rloo, that's how I see it yes... tho time is always a problem 19:19:22 * JayF cares more about specific hardware configuration not ending up as a "public" API in Ironic 19:19:25 JIT hardware reconfigure 19:19:28 whereas. I wouldn't want everyone to spend time discussing the changes for a single driver there 19:19:31 it seems to me that the spec process is a good way to get the design down. 19:19:57 rloo: I agree - it is usually enough, but sometimes, not 19:20:13 rloo: hardware discovery is another one. we've had a LOT of specs for that and no real agreement yet 19:20:24 devananda: so we should focus on those features that we think would benefit from people being there. 19:20:35 face-to-face, with tomatoes or whatever. 19:20:39 exactly 19:20:50 gotcha ;) 19:21:16 and things which may not require quite as wide an audience could then get scheduled for unconference / hackathon / BoF time 19:22:12 link for the openstack brownbag techtalk schedule http://openstack.prov12n.com/vbrownbag-techtalk-schedule-at-openstack-summit-paris-2/ 19:22:27 #link http://openstack.prov12n.com/vbrownbag-techtalk-schedule-at-openstack-summit-paris-2 19:22:35 * lucasagomes googles BoF 19:22:47 birds-of-a-feather 19:23:03 * dtantsur still does not understand :( 19:23:17 BoF = informal after hours have pizza and beer together and talk about something 19:23:27 dtantsur: what can I help clarify? 19:23:35 you just did :) 19:23:42 :) 19:23:56 and/or on Friday's contributor meetup. 19:24:18 oh, also, I'd like to ask everyone - how many folks want to (and what's a good night to) have an Ironic team dinner? 19:24:31 +1 19:24:38 +1 19:24:40 +1 19:24:41 and would folks prefer a proper dinner or an open birds-of-a-feather session? 19:24:56 devananda: define them both? 19:25:10 both will end up on discussions no? 19:25:17 dinner = ironic ATC's get an invite to a restaurant 19:25:22 dinner with friends, who may happen to chat about worky things too 19:25:28 BoF sounds better to me, informal and we get to talk 19:25:38 BoF = we order lots of take-out food to be delivered to the conference hall after-hours and sit around chatting with whoever shows up 19:25:53 I'm fine with either, but we should definitely get together 19:26:04 +1 jroll 19:26:06 both sound nice :) 19:26:28 if pressed to vote I'd vote informal 19:26:38 but am okay with either 19:26:58 I've heard two votes for informal, none for formal 19:27:00 * dtantsur has a modification to BoF variant with setting under the Eiffel Tower, but not sure about whether 19:27:08 * sitting 19:27:12 dtantsur: heh. I hear it rains a lot in early November 19:27:38 giving it another minute before we move on ... 19:27:42 as long ad takeout food is good ;) 19:27:45 ad -> as 19:27:50 it will be cold too 19:27:50 rloo ++ 19:28:05 informal at a restaurant? 19:28:10 lucasagomes: yea. cold and rainy. 19:28:26 plus loads of people around the tower 19:28:31 rloo: that's a party. there are already lots of those planned ;) 19:28:58 informal at a restaurant without LOUD music ;) 19:29:12 ok, I'll start scheduling a BoF, probably later in the week as Mon-Wed I will probably be busy 19:29:29 devananda: ++ 19:29:32 can't wait to see all of you :) 19:29:41 that probably means Thur, cuz Fri evening might not be good. 19:29:41 #topic sub team reports 19:29:53 adam_g: hi! any news on the CI front? 19:30:07 so im still trying to get our grenade job functional again after fallout from some devstack changes 19:30:16 fixed one issue, but another has slipped through 19:30:42 also going through the parallel failures that are still occurring and trying to do a quick triage of each to see what failures are real and which are transient 19:31:02 adam_g: the grenade job will move to stable/juno once that branch is cut, so we just need trunk working for another two weeks, right? 19:31:33 i'd like to propose we get our stuff voting in other projects (namely devstack, tempest, grenade) before we make them voting on ironic. increasing # of running jobs increases the risk of breaking changes merging elsewhere 19:31:35 adam_g: actually, nm. juno-rc is tagged on everythign already 19:31:57 adam_g: yea, those three ++ 19:32:38 are there any issues that would prevent that from happening now that we are fully graduated? 19:33:10 adam_g: for devstack/tempest/grenade, none that I know of 19:33:28 adam_g: for nova, I *think* it's fine to start voting there too, now, since kilo is open 19:33:50 adam_g: nova may or may not want the grenade job to vote on stable/juno -- that's up to them. I think it should, and I think they'll want it to 19:34:03 but that's not spelled out in the gov guidelines 19:34:29 sdague: if you're around, have a minute to answer test/voting questions? 19:34:51 okay, i'd still like to give the parallel tempest job and grenade a bit to stabilize and find bugs, but the current check-tempest-dsvm-ironic-pxe_ssh has proveb to be stable and should be good to vote 19:35:24 adam_g: sounds good 19:35:26 dtantsur: how are our bug stats looking? 19:35:40 pretty well 19:35:42 Open: 89 (-5). 4 new (+1), 21 in progress (-5), 0 critical, 9 high (-3) and 4 incomplete (0) 19:36:00 added one about ceilometer fields naming 19:36:00 nice 19:36:10 great numbers :) 19:36:11 I'd ask someone to have a look at it 19:36:16 :) 19:36:16 #link https://bugs.launchpad.net/ironic/+bug/1377157 19:36:24 Launchpad bug 1377157 in ceilometer "ipmi sensor naming in ceilometer is not consumer friendly" [Undecided,In progress] 19:36:42 ceilometer team seems to agree that it's a bug in their meter naming and, i think, is working on a fix for Juno 19:37:11 so we can confirm it? 19:37:16 devananda: Juno? is there a review? 19:37:30 yeah, we may want to mark that as invalid/won't fix for Ironic 19:37:35 lucasagomes: ++ 19:37:53 ah, so we can't fix it? 19:37:57 * dtantsur is confused 19:38:18 though, also, Jim Mankovich is going to be proposing some changes to Irnoic during Kilo to improve sensor data handling for non-ipmi drivers 19:38:27 dtantsur, the bug is not in Ironic, it's the way the data is consumed/transformed in ceilo 19:38:51 ah I see. won't fix then? 19:38:52 NobodyCam, https://review.openstack.org/#/c/126397/ 19:39:22 dtantsur, +1 for me 19:39:25 k, i'll update teh bug in Ironic 19:39:38 thanks 19:39:39 I dont have any other bugs to discuss -- anyone else? 19:39:48 ahh ok that was put up today 19:40:01 also https://bugs.launchpad.net/ironic/+bug/1239481 <-- long-standing, people say it's serious, I don't understand as well :( 19:40:04 Launchpad bug 1239481 in neutron "nova baremetal requires manual neutron setup for metadata access" [Undecided,Confirmed] 19:40:17 deva, so for the hw sensor that Jim is proposing should I enter it inthe spreadsheet? 19:40:22 does that affect ironic? 19:40:43 wanyen: sure, but I suspect it's a fairly simple change and won't need summit discussion time 19:40:52 Yes. It will have someimpact as we want to be able to emit sensors to other destination 19:41:17 jroll: you and wanyen / jim should chat about statsd integration 19:41:36 that is proposed by aweeks 19:41:38 not by jroll 19:41:38 dtantsur: that bug is very old. are we sure it's still a problem for Ironic? 19:41:46 re: statsd integration 19:41:46 we want to emit data to monasca 19:41:55 devananda, I am not definitely 19:41:56 JayF: ah, right. I keep tagging him for everything ... sorry :p 19:42:18 devananda: that's explicitly why I corrected it :P we have a whole group of people here 19:42:38 dtantsur, hmm I don't know much about it too... but sounds like something that nova would do when creating the instance, and ports in neutron etc... 19:42:47 idk if we can do something in our end to fix that 19:43:22 dtantsur: ah, ok. yes, that definitely affects Ironic 19:43:36 dtantsur: it will be problematic for any Ironic deployment larger than a single L2 domain 19:44:09 devananda, mind confirming/triaging please? 19:44:20 dtantsur: confirmed. not sure of priority since I'm actually not sure the fix lies within Ironic at all 19:44:34 I suspect the fix is "use a neutron plugin that supports your HW switch" 19:44:39 but need to dig in more 19:44:56 well, we need to have some priority IIRC 19:44:58 #action devananda to follow up on https://bugs.launchpad.net/ironic/+bug/1239481 19:44:59 Launchpad bug 1239481 in neutron "nova baremetal requires manual neutron setup for metadata access" [Undecided,Confirmed] 19:45:05 cool thanks 19:45:06 moving on so we dont run out of time 19:45:10 that's all :) 19:45:21 GheRivero: hi! 19:45:38 GheRivero: if you'd like to continue being our oslo liaison - I think taht's great. thanks! 19:46:23 +1 vote for GheRivero 19:46:28 :-p 19:46:38 anyone else want to work with oslo team on osloification of things? 19:47:01 ok :) 19:47:04 devananda: ? you mean if GheRivero doesn't? 19:47:17 drivers! wow, we're running out of time too 19:47:34 jroll: wanyen: linggao: hi! any news from the driver side of things? 19:47:46 I have nothing afaik :) 19:47:55 Hi devananda, nothing new from here. 19:48:23 great 19:48:25 does that include rpc objects? 19:48:32 I know ya'll are working on CI for each of your respective drivers 19:48:33 of so I'd like to help to oslofy it 19:48:33 we are doing internal review for the doc. Are there any quideline for vendor driver in terms of what to submit and what to put on the ilo driver wiki? 19:48:40 if so* 19:48:50 I was pinged by stackalytics folks re: https://wiki.openstack.org/wiki/DriverLog yesterday 19:48:59 I meant docment quideline for vendor drivers 19:49:00 so I've posted some initial bits to get that going for Ironic 19:49:37 devananda: neat 19:50:11 #link https://review.openstack.org/#/c/126369 19:50:20 10 minutes to go before the bell 19:50:22 anything wrong there, feel free to tell me or post on top of 19:50:57 wanyen: anything a user of the driver would need to know -- like config options, how the environment must be set up (esp. how it is different from other drivers) 19:51:18 lucasagomes: you mentioned adding DRAC to the drivers section of the meeting -- I did 19:51:24 lucasagomes: but I'm not sure whothe point of contact for that is 19:52:06 deva, tx 19:52:11 did I? well ifarkas would be a good point of contact but he's busy 19:52:23 devananda: if I make a comment on that review, mind adding some more IPA maintainers? 19:52:25 so maybe myself as I have access to a DRAC and can test stuff 19:52:38 lucasagomes: ack, thanks 19:52:44 jroll: dont' mind at all 19:52:50 thanks 19:52:59 moving on then 19:53:02 #topic open discussion 19:53:18 #link https://review.openstack.org/#/c/99426 19:53:25 thanks NobodyCam for adding that ^ 19:54:21 just a open question should test ass items in to the ironic.conf. <- in ref to : https://review.openstack.org/#/c/125361/2/ironic/tests/db/base.py 19:54:46 s/ass/add/ 19:54:48 :-p 19:55:08 NobodyCam: nooooo 19:55:14 so folks, r you guys happy to remove things like local_gb, memory_mb etc... and have a generic name where we can add suffixes for the values to determine the unit size? 19:55:21 ironic.conf.sample should be a good starting point for production use 19:55:24 NobodyCam: ^ 19:55:32 NobodyCam: that's very odd looking to me 19:55:40 (ofc we need to leave those options to be backward for cycle at least) 19:55:52 lucasagomes: yep. backwards compat ++ 19:55:59 NobodyCam: there's probably a way to do that 19:56:07 lucasagomes ++ 19:56:16 ack just wanted to point that out 19:56:27 lucasagomes: I'd like to see the nova driver impact but generally +1 19:56:38 lucasagomes: it may be worth noting that our API doesn't expose -any- means to indicate to a user that certain "properties"fields are expected / compatible / deprecated / removed 19:57:15 jroll, not much, well... these values comes from the flavor so we just need to change the way we create the json patch in nova (as far as I see it) 19:57:22 lucasagomes: something like num_cpu and ram_gb aren't actually used by Ironic today (though they could be in some esoteric hardware) werehas local_gb *is* used 19:57:34 lucasagomes: right, the driver would tack on the unit string, yes? 19:57:40 devananda, oh yeah, indeed. We can add a doc, and a LOG if those options are used 19:57:40 lucasagomes: if we change that, anyone who is not using Nova will be affected and unaware of it 19:57:49 jroll: right 19:58:01 jroll, yup... 19:58:30 I'm still a bit confused why we don't just assume MB everywhere :/ 19:58:36 also flavors are opinionated about the unit sizes right now (just like we are), so it would patch with memory=512MB for e.g 19:58:41 and we convert it in ironic 19:58:44 NobodyCam: I think your question is, should CONF options be defined in the unit tests, not how taht relates to our sample config file 19:58:56 jroll: because Nova 19:59:14 devananda: convert it in the driver 19:59:18 jroll: ++ 19:59:20 either way we're messing with it 19:59:29 like... don't see the use case for accepting gb 19:59:30 oh 19:59:30 so 19:59:33 jroll, that was my 2nd attempt of fixing the unit inconsistency (1st was everything GB), but got some push backs... so maybe having it very flexible is good 19:59:39 devananda: yes .. much better wording 19:59:43 one minute 19:59:46 the reason is, we don't SET it from the nova driver, Nova reads it from Ironic 20:00:03 beep 20:00:03 devananda: ...through the driver interface 20:00:10 and we need Nova to understand when it reads "512" from Ironic what that means in terms of its flavors 20:00:20 anyhow, lets continue that in channel 20:00:22 thanks all! 20:00:25 thanks 20:00:25 cheers 20:00:26 thanks 20:00:27 great meeting 20:00:30 #endmeeting