17:00:23 #startmeeting Ironic 17:00:23 #chair devananda 17:00:23 Meeting started Mon Feb 9 17:00:23 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:24 Welcome everyone to the Ironic meeting. 17:00:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:27 The meeting name has been set to 'ironic' 17:00:28 Current chairs: NobodyCam devananda 17:00:32 o/ 17:00:37 hey all o/ 17:00:40 o/ 17:00:41 Of course the agenda can be found at: 17:00:41 #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting 17:00:42 o/ 17:00:45 o/ 17:00:45 o/ 17:00:49 #topic Greetings, roll-call and announcements 17:00:50 o/ 17:00:50 Roll-call: Who's here for the Ironic Meeting? 17:00:57 ahoy! 17:00:58 o/ 17:01:01 o/ 17:01:03 o/ 17:01:03 howdy ya'all 17:01:10 o/ 17:01:14 \o/ :) 17:01:25 o/ 17:01:26 \o 17:01:38 \o 17:01:51 devananda: is getting some coffee so may be a minute late 17:01:55 announcements: 17:02:17 one meetup (sprint) down 17:02:30 another (in San Fran) in a couple of days 17:02:36 woohoo 17:02:39 o/ 17:02:42 whos going to be at the SF sprint 17:02:47 o/ 17:02:49 last week's sprint went very well, IMHO 17:02:50 o/ 17:02:52 o/ 17:02:56 * jroll is already there 17:03:07 * GheRivero says hi 17:03:07 ahh welcone devananda :) awesome to hear 17:03:14 hi GheRivero :) 17:03:30 devananda, +1 that was great 17:03:33 with ~10 ppl, it felt like we all were able to actually get things done 17:03:47 saw some great ski photos :) 17:04:07 :D 17:04:23 :) anything else for announcements? 17:04:41 just one 17:04:54 kilo-2 was tagged last week, for those who weren't watching 17:05:10 for the list of what blueprints were completed: https://launchpad.net/ironic/+milestone/kilo-2 17:05:10 :) 17:05:31 I have yet to post a complete CHANGELOG, but will try to do that today 17:05:34 that's it for me 17:05:35 I also sow a couple bp got bumped to k3 17:05:53 yah. anything not done by thursday was bumpbed automatically 17:06:04 #link https://launchpad.net/ironic/+milestone/kilo-3 17:06:05 wow, 40 bugfixes, love it 17:06:18 moving on ... 17:06:20 yay to everyone (us) for contributing to kilo-2 :-) 17:06:31 #topic subteam status reports 17:06:35 https://launchpad.net/ironic/+milestone/kilo- 17:06:39 doh 17:06:48 deva, like toadd secure boot to kilo3 17:06:58 did we get a status report after last weeks meeting? 17:07:03 I've been really bad about sending subteam reports :/ 17:07:16 :) 17:07:18 is there anyone else willing to do that, that can do a better job? 17:07:30 it was kinda a small meeting lastweek 17:07:33 jroll: I can help you 17:07:50 rloo: that would be great, even just a reminder would help :) 17:08:03 jroll: we can discuss how many beers later ;) 17:08:07 also, sorry IPA broke the gate :P 17:08:08 rloo: can I ginve you a #action item for that? 17:08:10 haha 17:08:13 NobodyCam: yup 17:08:23 wanyen: I'll do what I can with Nova to get the capabilities change approved over there. I know it's just a small patch.... 17:08:38 devananda: I'd like to know the status of new state machine transition 17:08:39 wanyen: as far as secure boot, what is the spec name? 17:08:40 #action rloo to start helping jroll with status reports after meeting 17:08:46 naohirot: which transition? 17:08:57 devvesa, yeah, that patch is also blocking the local boot one 17:08:59 hope they accept the FFE 17:09:04 devananda: I saw your patch https://github.com/openstack/ironic/commit/e7958dee652ecd961a90eafd2c0411bc464b0adb 17:09:07 I will find the name for secure boot 17:09:18 devvesa, sorry I meant devananda 17:09:28 lucasagomes: capabilities change in Nova is blocking our local boot support? 17:09:29 * lucasagomes can't dev here 17:09:37 devananda: but there is still NOSTATE here https://github.com/openstack/ironic/blob/master/ironic/tests/drivers/ilo/test_deploy.py#L388 17:10:01 devananda: does that mean that the code transition is still on going? 17:10:07 devananda, yeah, local boot is set as a capability which is then passed via the Nova Ironic driver to the instance_info 17:10:12 naohirot: that's target_provision_state 17:10:18 naohirot: where NOSTATE is valid 17:10:26 we could change that tho, I was mostly following a spec that was upstream and I took over 17:10:54 lucasagomes: capability for the flavor? hrm 17:11:02 jroll, yeah 17:11:03 jroll: I see, target_provision_state still is valid to be NOSTATE. 17:11:06 * jroll thinks we may be way off topic here on many threads 17:11:06 naohirot: all "stable" states will continue to have target_provision_state == NOSTATE 17:11:10 deva : https://review.openstack.org/#/c/135228/ and https://review.openstack.org/#/c/135845/ 17:11:11 jroll: yes :( 17:11:38 our agenda is light today 17:11:47 devananda, jroll yeah we are a bit off, but we can talk about it later... we could do it differently, but I will have to update the spec 17:11:50 devananda: jroll: I'll check the new state machine blue print again 17:12:09 devananda: secure boot spec for ilo drivers: https://review.openstack.org/#/c/135228/ 17:12:45 devananda, one query(may be we can take up in open dsicussion)...dtantsur has posted a comments states patch for inspection that the transient state INSPECTED may not be needed noe 17:12:49 #action devananda to update launchpad status for several approved specs 17:13:01 ok, we've really gone off topic now folks 17:13:01 s/noe/now 17:13:13 this should be a time for driver maintainers to share their status 17:13:25 anything else on subteam status' 17:13:30 wanyen was pointing out that the ilo driver has some approved specs that are not targeted or reflected in launchpad 17:13:39 question about IPA breaking the gate -- is there no way to see if it breaks the gate first, before making the change? 17:14:04 rloo: the nova configdrive patch landed, and that's when it broke, configdrive was not being tested in gate previously 17:14:17 rloo: thats tuff at least how I see things 17:14:26 jroll: ahh. ok thx 17:14:33 #action devananda and wanyen to work with Nova team to try to land the capabilities-related change to ironic driver 17:14:35 jroll, oh didn't know that 17:14:39 rloo: ipa has tempest jobs that test ipa with ironic, ironic has tempest jobs that test ipa with ironic, it should generally be fine 17:14:46 deva, tx 17:14:49 nova only has tempest jobs for ironic with pxe_ssh 17:14:57 wanyen: did you get ffe for that? 17:15:08 lucasagomes: no worries, not your fault, apparently partprobe doesn't work on the VMs that the ssh driver uses :| 17:15:10 adam_g hasn't chimed in yet, but I believe he started looking at tempest-lib'ifying our functiona ltests 17:15:17 NobodyCam, requested FFE in mailing list already 17:15:19 eg, moving them out of tempest and into ironic's tree last week 17:15:19 I submitted ffe but I have not got approval 17:15:26 jroll, urgh... I see 17:15:33 devananda: +1 17:15:50 AIUI there is still a lot of work to do there, not just in Ironic, so there was no concrete progress 17:15:51 is there a #link for the request we can post here? 17:16:54 on the oslo side, I believe the oslo'ification of the Object code is still blocked on dhellmann. and not really a priority for anyone this cycle 17:16:55 NobodyCam, http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg45394.html 17:17:22 oh, and one more thing 17:17:34 I proposed a novel change to how we classify drivers 17:17:44 to make it more clear which drivers are meant for production -- and which are meant for testing environments 17:18:09 I'm raising it here because it affects driver maintainers (which is what this section is about) 17:18:09 #link http://lists.openstack.org/pipermail/openstack-dev/2015-February/056256.html 17:18:12 #link https://review.openstack.org/#/c/152056/ 17:18:31 I would like to elicit feedback from the driver authors on this patch before doing any more work on it 17:19:19 on teh review -- not right now :) 17:19:35 ok, that's all for me. any other last words before we move on? 17:19:45 should we update the #topic? 17:19:51 :) 17:19:52 NobodyCam: I will shortly 17:20:05 devananda: I'll certainly take a look 17:20:22 naohirot: thanks 17:20:39 devananda: you are welcome 17:20:42 #topic whether or not RAID should have a separate interface 17:20:51 rameshg87: you're up -- anything to discuss? 17:20:53 this spec landed on friday 17:21:14 there were some opinion that for raid configuration should use management interface instead of a new RAIDInterface 17:21:28 there were people for it and against it 17:21:53 so just thought we could discuss it out here. spec has landed by the way. but i would like to get everyone's thoughts 17:21:53 what was decided? 17:21:58 rameshg87: can you summarize both sides of the debate? 17:22:09 what are the pos/cons people pointed out? 17:22:10 link to spec? 17:22:21 rloo, raid configuration on bare metal node requires methods 17:22:33 rloo, i meant https://review.openstack.org/#/c/135899/ 17:22:51 #link http://specs.openstack.org/openstack/ironic-specs/specs/kilo/ironic-generic-raid-interface.html 17:22:53 #link https://review.openstack.org/#/c/135899/ 17:22:57 \o 17:22:59 raid configuration requires methods to create and delete the raid configurations on bare metal node 17:23:12 my only concern with the RAIDInterface is that our driver matrix is growing at an exponential rate, and we need to find a better way to handle it 17:23:13 currently proposed one is a new RAIDInterface which will be a new attribute to the driver 17:23:39 as opposed to we could be having the new methods in ManagementInterface itself 17:23:49 we need to rething how we're naming our drivers 17:23:53 jroll, we already have it pretty insane :D 17:24:06 right 17:24:12 rameshg87: what is the benefit to using a separate interface? 17:24:15 (and we used to have for some time, if we count console and vendor interfaces) 17:24:27 will the RAIDInterface be a standard interface? (I should read the spec before asking) 17:24:45 rloo, yeah, I assume it's 17:25:02 I don't want to necessarily block this on that fact, however I think we really need to start figuring this ouy 17:25:05 s/ouy/out/ 17:25:10 core is only what is really needed to put workload on a node 17:25:14 like power and deploy 17:25:42 devananda, my opinion it's just the cleaner approach. raid being new functionality that we introduce could demand it's own interface 17:26:15 jroll: let's dive into that this week, then. I think we are all concerned about it 17:26:44 indeed 17:26:47 +1 17:26:54 but idk, RAID is a very vendor specific thing no? 17:26:56 one aspect to point out -- having this as a separate interface means that support for it is discoverable in the REST API 17:27:02 via node-validate 17:27:04 I mean, management should be common ground across drivers 17:27:27 if it were part of ManagementInterface, then all nodes that support the management functions would need to support RAID as well 17:27:33 which they may not 17:27:47 devananda, ++ 17:27:52 yeah, they can't not 17:27:52 or it would violate the API contract whereby a driver supports only some of the management commands but not all 17:27:55 can not* 17:27:57 + 17:28:07 console is in ManagementInterface and that isn't supported by all drivers 17:28:08 that's my reason why I prefer it in a separated interface 17:28:14 but well, I could argue both sides really 17:28:23 rloo, console is a separate interface IIRC 17:28:26 rloo: that makes me sad. I like things to be consistent. want to file a bug? 17:28:33 dtantsur: oh, is it? 17:28:37 * rloo checks 17:28:41 rloo, may be sensors 17:28:44 rloo, yeah console is separated 17:28:49 sensors is mgmt 17:28:49 oh yah. console is separate 17:28:49 rloo, yeah, console is separate 17:28:53 I thouht it was 17:29:03 * rloo wrong. Sorry, it was sensors I was thinking of. 17:29:11 maybe we should brainstorm, what should be part of each interface 17:29:18 come up with some guides 17:29:21 very clear 17:29:30 lucasagomes: ++ 17:29:38 maybe in SF 17:30:00 NobodyCam, could be, but keep me in the loop pls :( I won't make it to SF unfortunately 17:30:10 ya ofc :) 17:30:13 isn't thatd already be documented in-line? if not, it should be 17:30:19 on the drivers/base.py module 17:30:39 """Interface for management related actions.""" 17:30:47 not very specific 17:30:48 devananda: I feel a clearity doc would only help 17:30:55 yup 17:30:59 it definitely is 17:31:02 my only concern is keeping it up to daye 17:31:06 lucasagomes: look down. each method on taht interface has a doc string 17:31:11 and they're all abstract 17:31:20 so any driver implementing ManagementInterface has to implement those 17:31:44 anyway, if folks feel that can be improved -- please feel free to do so :) 17:31:51 I just want to avoid havign docs in two places for the same thing 17:31:55 devananda: I think they implement and return some NotImplemented exception 17:32:05 rloo: oh. that's ... bad 17:32:15 devananda, right, I was thinking about new methods... like if you want to add support for something, should it go to the mgmt interface ? e.g is it something common which all drivers could implement 17:32:19 drivers shouldn't get to say "I'm only half a driver" and still be allowed in tree 17:32:23 * lucasagomes not sure, thinking out of loud here 17:32:33 vendor_passthru is the place for that 17:32:49 anyway ... we're now quite far off topic again :) 17:32:54 eg get_sensors_data 17:33:00 heh yeah, let's talk about it later 17:33:05 this sounds like a good discussion to have at the meetup, too 17:33:08 add to the SF agenda :) 17:33:31 #topic is the install-guide complete, w.r.t. neutron setup? 17:33:35 mjturek1: hi! you're up 17:33:44 hey! really nothing urgent, but just thought I'd bring it up here. 17:33:56 I noticed a missing step in the installation guide last week (subnet creation step -- already patched and committed). 17:34:08 mjturek1: and thank you for your doc patch for subnet setup 17:34:12 which had me wondering how complete the guide is as I've had some issues with getting a setup working using it, though it may be some networking problems on my end. 17:34:19 NobodyCam np :) 17:34:28 There is already an initiative to get the installation guide improved https://bugs.launchpad.net/ironic/+bug/1323589 17:34:28 Launchpad bug 1323589 in Ironic "Installation guide needs updating" [Medium,In progress] - Assigned to Chris Krelle (nobodycam) 17:34:36 mjturek1: there is always room to improve our docs 17:34:50 NobodyCam, very true. Just wanted to push to possibly get a few more eyes on it (the guide and the bug page). 17:34:52 me? 17:34:58 mjturek1: good question. I believe haomeng had been doing some work on that 17:35:10 mjturek1: but largely it's user contributed, so please continue fixing things you find missing 17:35:25 devananda, okay fair enough :) will do 17:35:37 awesome thank you mjturek1 :) 17:35:43 thanks! 17:35:48 mjturek1: cheers. thank you! 17:35:57 #topic open discussion 17:36:10 wow OD with > 20 minutes 17:36:21 thats a first :) 17:36:22 oh .. so I do need to ask folks about the summit 17:36:25 #undo 17:36:26 Removing item from minutes: 17:36:29 #topic summit planning 17:36:37 jroll, wanna talk about the local boot capabilities thing? 17:36:44 i have a question to ask in open-discussion 17:36:44 oh ok, wait for OD again 17:36:50 usually the layout of design summit sessions is done a little later 17:36:51 heh 17:36:58 I'll be driving up to SF tomorrow and mostly off line 17:37:04 but ttx needs us to decide soon how many sessions we want to have 17:37:12 devananda: all the sessions 17:37:17 +1 :) 17:37:18 split between big "fishbowl" style -- everyone in a big room 17:37:20 devananda: or at least provide a wild guess 17:37:25 devananda, what I really felt on the last summit is that when we got the room for ourselfs 17:37:30 for half a day it was very productive 17:37:34 and smaller "working" sessions where it's just us and a whiteboard, basically 17:37:41 better than having sessions the normal way 17:37:47 and then whether we have half or a whole day on friday 17:37:56 if we could have a room for at least one full day, that would be awesome 17:37:57 my impression is that "us and a whiteboard" works much better 17:38:00 the "workign" sessions are a new style we have never had before 17:38:39 we could have a normal session for operators give feedback tho 17:38:50 idk how much it worked last time, but it's good to keep it open 17:38:51 the fishbowl sessions were useful for ^^ what lucasagomes just said 17:38:52 I kinda felt like we had to many seesions last summit, I would vote to limit topics 17:39:04 here's what I'm leaning towards -- 2 fishbowl sessions (one general project things and one for operators) 6 working sessions (for what ever) and then a whole day friday 17:39:36 I liked the unstructured time, although most people just hung around the state machine discussion, and very little other work was done. So I think we need a mix of both. 17:39:38 devananda, sounds good 17:39:40 what's the diff between working sessions, whole day Friday? 17:39:53 I say that only because I missed a bunch of the state stuff which if we had all been focused *may* have landed quicker 17:39:55 rloo: working sessions are on tue/wed/thur 17:40:01 like a hackaton I believe ? 17:40:17 devananda: but what is done at working sessions that is diff than what we'd do on Friday? 17:40:17 we can do less working sessions if we think we'll want to be in other tracks 17:40:24 eg, nova, cross-project, etc 17:40:42 rloo: only that they have a formal topic and get listed in the schedule 17:40:53 rloo: well, and we could NOT give them a formal topic, if we wanted to 17:41:09 I like the two Fishbowl sessions and rest as working 17:41:22 but they COULD have one. whereas friday definitely does not have a presence in the scheduling app 17:41:24 the large fihbowls tend to side track 17:41:26 devananda: so working sessions would sort of be/replace the pod stuff that didn't work 17:41:31 rloo: exactly 17:41:39 there will be no pods this time 17:42:24 it sounds like I'm hearing that folks like my suggestion of 2 fishbowl / 6 working / unstructured all day friday 17:42:32 seems fine to me 17:42:35 +1 17:42:36 ++ here 17:42:39 interesting. I guess it depends on what the other projects do too. cuz before we'd sit in on nova etc sessions, I don't know now if those would be fishbowl or working. 17:42:57 rloo: taht's up to those PTLs ... I dont know either at this point 17:43:49 how many fishbowl did we have last summit? 17:43:54 rloo: 5 17:44:01 and a half day friday, and no working sessions 17:44:13 thanks for the input, everyone 17:44:34 hmm. am worried that 2+6 would be too many, if people want to attend others that overlap, but we could try and see. 17:45:01 * mrda-sfo thinks we were a little light on with sessions last summit, fwiw 17:45:21 rloo: I'm sure we can adjust as the other sessions harden there paln 17:45:26 plans even 17:45:36 haha, I thought NobodyCam said 'pain'. 17:45:43 we're always trying something new as things keep changing rapidly :) 17:45:46 we probably will re-revise it when they start making the conference schedule 17:45:54 ++ 17:45:58 #topic open discussion 17:46:06 jroll, yo 17:46:14 microversioning -- should we announce/mention how to use it? 17:46:24 rloo: yes! 17:46:31 jroll, so, I thought it would make sense to say, give me a machine with local boot and using flavor as the way to ask for it 17:46:35 * lucasagomes maybe I was wrong? 17:46:39 rloo: folks should read the nova spec 17:46:45 do we need a how to bump the microversion type doc? 17:47:00 http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/api-microversions.html 17:47:01 or is spec good enough? 17:47:05 lucasagomes: sure, that's fine... though I don't know that the user always cares. or maybe the operator wants to decide (make all flavors localboot?) 17:47:10 lucasgomes, +1 17:47:11 INSPECTED - should this state be removed? 17:47:18 Nisha: why? 17:47:30 jroll, yeah, exactly it's possible 17:47:34 I think we need something more than spec. The spec mentions using decorators that we're not using. 17:47:44 devananda, there is a suggestion from dtantsur on code changes for inspection 17:47:58 jroll, sounds like an operator decision to me whether the instances will always localboot or only some of them will 17:47:59 Nisha: #link? 17:48:01 rloo: refactoring what we have to use decorators ++ 17:48:09 yeah, I'm a bit confused by these *ED states 17:48:12 so just wanted to have everyone's opinion 17:48:14 lucasagomes: ok, maybe it's fine, I just haven't thought about it much 17:48:16 #link https://review.openstack.org/#/c/147857/ 17:48:17 rloo: or something else, maybe something like version-utils 17:48:23 ty :) 17:48:41 on the *ED states, my intent was to provide an optional hook for additional call backs 17:48:44 jroll, cool, np, yeah we can think over it 17:48:51 see if it really makes sense 17:48:55 yep :) 17:49:32 devananda, one ques then how does the node then move from *ED (INSPECTED) to some stable state (in thi case MANAGEABLE) 17:50:11 Nisha: on the completion of what ever callback is triggered by INSPECTED, the "done" action would move it to the next state, namely MANAGEABLE 17:50:16 devananda, in my code changes i am not sure when to move the node from INSPECTED to MANAGEABLE 17:50:26 Nisha: however, since no drivers are using this now, I'm fine if we skip over that transition 17:50:39 Nisha: or if we implement it as a no-op 17:51:06 devananda, ok 17:51:08 but for example, I can envision the CLEANED state performing a re-verification of the node before moving it to MANAGEABLE 17:51:10 no-op sounds more flexible 17:51:22 +1 for no-op in that case 17:51:47 hmm i like that idea for CLEANED 17:52:00 no-op would be my preference 17:52:06 +1 17:52:08 +1 17:52:12 ok :) 17:52:13 +1 17:52:26 ok, it's clearer now :) 17:52:30 #agreed implement the CLEANED state transition using a no-op for now, to allow it to be extended by drivers later on 17:52:46 devananda, its INSPECTED 17:52:51 oops 17:52:52 #undo 17:52:53 Removing item from minutes: 17:52:57 CLEANED too 17:52:58 #agreed implement the INSPECTED state transition using a no-op for now, to allow it to be extended by drivers later on 17:53:04 wouldn't we want to do a similar thing for all *ED states? 17:53:04 I was asking about it as well IIRC :) 17:53:06 sounds like it's *ED states 17:53:11 rloo: yep 17:53:18 #undo 17:53:19 Removing item from minutes: 17:53:26 #agreed implement all the *ED state transition using a no-op for now, to allow it to be extended by drivers later on 17:53:29 hehe 17:53:32 +1 :) 17:53:58 :-p 17:54:07 +1 17:54:17 NobodyCam: as far as "how and when do we bump the API microversion" -- I think that would be a good wiki page 17:54:34 developer doc maybe? 17:54:44 Five minutes left 17:54:47 :) ++ 17:54:49 lucasagomes: maybe? let's start on wiki to iterate more quickly 17:54:58 wiki is good but not sure if many people look at it 17:55:11 in the dev docs we have things like how to create a vendor passwhtru method etc 17:55:14 I think wiki sounds good 17:55:17 especially if rloo is going to encourage us to use a decorator rather than the functional checks I implemented 17:55:18 if its there we can reffer (point) folks to it 17:55:19 devananda, ah right, like a draft? 17:55:20 ok 17:55:24 lucasagomes: right 17:55:31 * rloo stays quiet... 17:55:35 but how do we go about reordering, when a patch gets delayed and a later revision lands before the earlier one? 17:55:35 :-p 17:55:51 cool :) 17:55:56 * lucasagomes assigns the work to rloo 17:55:56 mrda-sfo: example? 17:55:58 jk :) 17:56:00 mrda-sfo: that's going to be tricky. but we have the same challenge with the RPC API 17:56:15