17:01:52 #startmeeting ironic 17:01:54 Meeting started Mon Dec 15 17:01:52 2014 UTC and is due to finish in 60 minutes. The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:55 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:57 The meeting name has been set to 'ironic' 17:01:59 o/ 17:02:15 o/ 17:02:25 g'morning / afternoon / evening / middle of the night to everyone :) 17:02:37 good morning 17:02:42 #topic announcements 17:02:49 o/ 17:02:52 I added a couple of items to the agenda late (just this morning) 17:03:05 one hopefully quick announcement 17:03:12 o/ 17:03:38 I'm working on getting details for the midcycle, like hotel and what not, and will distribute that once I have it 17:03:49 along with an eventbrite signup thing 17:03:50 awesome :) 17:04:02 nice one 17:04:08 grenoble seems farther away from airports than I realized 17:04:28 but it's a nice flat city with good local transportation 17:04:33 good opportunity to rent a fast car and drive through the back country :) 17:04:40 jroll: yup 17:04:42 lol 17:04:46 if that's your thing :) 17:05:15 that's it for me 17:05:24 can I bring my own car? 17:05:37 oh, also, welcome back to lucasagomes :) 17:05:37 sounds expensive :P 17:05:42 NobodyCam, lucasagomes - any announcements? 17:05:54 o/ thanks, it's good to be back 17:06:02 not really I'm still catching up with evrything I missed last week 17:06:09 k 17:06:15 #topic status board 17:06:19 not from me this time 17:06:41 NobodyCam: woops. jumped early there, sorry 17:06:54 following our new approach to weekly statuses, they are posted on the white board 17:06:57 #link https://etherpad.openstack.org/p/IronicWhiteBoard 17:07:05 let's take a minute to review, then raise any questions / concerns if we have them 17:07:09 (anyone can do that) 17:07:17 Thanks to every for the new status update format... is supper great to read them over the weekend and digest slowly 17:07:32 everyone* 17:08:14 iLO - "Setting up 3rd-party CI" \o/ 17:08:17 wanyen: ooh - third party CI will be great 17:08:26 sorry for some late additions, but oslo weekly meeting just finished :) 17:08:26 wanyen: have you been in contact with anteaya about that? 17:08:30 not sure what the HI bugs are, but do we need to try to get any in for kilo-1? 17:08:33 wanyen: I believe she coordinates the third-party-ci weekly meetings 17:08:52 I don't see dtantsur here? 17:09:09 I think he's afk (judging by his nickname) 17:09:12 deva, no. we requested an account already. 17:09:43 deva, okay. we will have someone attend the CI meeting 17:09:47 devananda: I didn't see the status report email in openstack-dev last week, are we going to send the status to the maillist this week? 17:10:01 jroll: ^ 17:10:07 wanyen: you don't request an account anymore it is self-serve 17:10:10 oops 17:10:26 naohirot: devananda: last week ended at 10pm for me, I completely forgot 17:10:32 jroll: yes, are we? 17:10:35 yes 17:10:37 wanyen: be sure to read this entire page: http://ci.openstack.org/third_party.html#creating-a-service-account 17:10:45 jroll: Okay 17:10:53 rloo, seems all the high bugs are in progress/fixed now 17:10:55 anteaya, tx 17:11:09 wanyen: welcome, I'll chat more in a third party meeting with you 17:11:18 there's one assigned to be that I don't think it's high priority as well (will reverify and change it accordingly) 17:11:28 lucasagomes: thx 17:11:28 naohirot, lintan: I noticed that the AMT driver proposal switched to using wsman instead of amttools 17:11:41 yes 17:11:41 terday 17:11:56 devananda: yes 17:12:36 to support amt better 17:12:41 naohirot: ack. just pointing it out here as I think that's something that other folks who were waiting for the AMT driver might want to know 17:12:42 devananda: I noticed that lintan is updating the spec. 17:12:58 Guest59984: who are you? :P 17:13:13 i am lintan 17:13:19 ok 17:13:39 2 minutes before we move on 17:13:55 Guest59984: you can fix your nickname with /nick lintan_ 17:13:58 since lintan is in use 17:14:24 devananda: I'm going to refer to AMT in order to know how to implement irmc. 17:14:38 rloo: some of those "high" bugs don't seem appropriately triaged to me. they've been open and marked "high" for months ... 17:14:59 rloo: perhaps it's time for us to have a bug-day again and just go through the list? 17:15:18 oh ++ 17:15:34 good to do somehting like that before the holiday break 17:15:41 devananda: yeah, but maybe next week? am wondering if we should spend this week trying to get patches in and maybe get specs moving along... 17:15:48 ok, let's talk about that in open discussion 17:15:56 I think it'd be great, but yea, when is a good question 17:15:57 devananda, +1 yeah there's one associated to me (the vendor passthru stuff) I just marked it as medium 17:16:01 cause def it wasn't high 17:16:10 thanks all, let's move on 17:16:19 bugday++ 17:16:26 #topic kilo-1 progress 17:16:37 #link https://launchpad.net/ironic/+milestone/kilo-1 17:16:53 rloo: ohhai - it's like you planned that ;) 17:17:11 honestly, I didn't... 17:17:13 so, it's probablyworth announcing for folks 17:17:27 #info last week we landed the new state machine spec 17:17:42 #link http://specs.openstack.org/openstack/ironic-specs/specs/kilo/new-ironic-state-machine.html 17:17:49 I've marked it as "Informational" in launchpad 17:18:00 because there is not a specific single body of code that's going to implement this 17:18:20 * lucasagomes will review the patches on gerrit asap 17:18:21 it represents the direction we all agree the project is headed, and *many* individual specs are going to be needed to get there 17:18:28 as we implement different aspects of the state machine 17:18:46 since we actually dont have *any* formally modelleled state machine today, I've been implementing one 17:19:05 I see NobodyCam put those links in the agenda in the next section -- so let's talk about that there 17:19:20 for now, i'm just calling it out as "a big thing that was on our kilo-1 priority list" 17:19:36 there are only 3 other blueprints targeted to kilo-1 17:19:54 so, if you own one of those, please speak up with the status now :) 17:20:04 does the xml bug need to land for -1? 17:20:17 lucasagomes: you still planning on doing pxe/configdrive stuff? 17:20:24 we'll be tagging the k1 milestone as soon as that page is all "implemented" -- whether things land, or get removed from the page 17:20:27 jroll, I will! for sure 17:20:40 jroll, I'm finishing up the root device thing and I will jump on that 17:20:46 lucasagomes: cool, I wonder if we should assign that blueprint to you then :) 17:20:50 probably won't finish on k-1 tho 17:20:56 jroll, +1 17:20:57 devananda: we might need to push back configdriev 17:21:12 jroll, we need to assign to u the boot/deploy ifaces as well 17:21:12 don't even have code up for the nova side yet so not a huge deal 17:21:23 jroll: ack. bumping it now 17:21:25 lucasagomes: yeah, is there a spec for that? 17:21:32 jroll, nop, but there's a blueprint 17:21:36 devananda: bumping to k-2? 17:21:40 i see that mrda put up code for "logical names" 17:21:41 as it was something that everybody agreeded 17:21:43 NobodyCam: yes 17:21:49 we didn't create a spec for it, we approved the bp straight away 17:21:54 lucasagomes: cool, I think it'll be january when I get to that 17:21:55 agreed* 17:21:59 #info "expose config drive to instances" bumped to kilo-2 17:22:03 jroll, ack 17:22:11 * lucasagomes assigns it to jroll 17:22:16 thanks 17:22:55 done, thank you :) 17:23:26 anything else on kilo 1? 17:23:36 as for xml support, it looks like mrda's patch was abandoned a month ago, and I don't see any new work 17:23:53 thats why I asked 17:23:55 as i update the amt spec, code is ready once the spec is approve 17:23:57 there's support in wsme now which should make it easy for us to do 17:24:12 Tanlin: is the code up already? 17:24:46 rloo: so to your question, it seems like there are only 2 specs up that have code ready for this week 17:24:54 logical names && AMT power driver 17:25:03 jroll: Tanlin has code up. I (ahem) objected to some of it. I think that's why the spec is being updated. 17:25:10 ha, ok 17:25:11 jroll: yes, except one tiny conf 17:25:14 jroll: would be good if others looked at it 17:25:19 yep 17:25:21 rloo: link? 17:25:47 https://review.openstack.org/135184 17:26:17 NobodyCam: https://review.openstack.org/#/c/135184/ 17:26:18 oh, I remember this debate 17:26:19 yes, i have some discussion with rloo and need your opinior 17:26:20 cool 17:26:31 * jroll would like to see the spec update 17:26:36 #link https://review.openstack.org/#/c/135184 17:27:23 #info AMT power driver spec needs revision, review is up. https://review.openstack.org/141269 17:27:38 #info AMT power driver still targeted to kilo-1 17:28:06 oh, also 17:28:16 #info python-ironicclient 0.3.2 released last week 17:28:20 * lucasagomes adds to the todo list 17:28:27 woohoo 17:28:33 oh nice 17:28:41 * NobodyCam will make an effort to review the AMT 17:28:43 just a minor release, but had support for some new features that will show up in kilo-1 17:28:47 review* 17:29:05 ok - about to move on, unless anyone raises something else 17:29:14 Cisco power driver spec is up for review 17:29:16 https://review.openstack.org/#/c/139517/ 17:29:53 #topic state machine 17:30:04 ah yes 17:30:14 this is the "CURRENT" state machine 17:30:42 devananda: have busted his rear on getting these reviews up (thank you devananda) 17:30:46 it likely needs work, any comments would be appreciated 17:31:12 I have listed the current reviews on the agenda page 17:31:40 the sooner we can land these patches, the better I feel 17:32:13 #link https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bp/new-ironic-state-machine,n,z 17:32:16 this gives us a good clear path for what we have now to what we are looking for fromthe NEW state machine 17:32:27 i'm good with the first review in that series once rloo's comments have been addressed 17:32:41 I started looking at those patches. I feel like they are a higher priority than the kilo-1 stuff. What do others think? (want to focus this week on hi-priority stuff) 17:33:13 i would say at teh same level as the k-1 stuff 17:33:59 these are all related-to a spec which I feel was essential for kilo-1 (the state machine) 17:34:03 speaking of.. how many folks are not around after this week 17:34:18 while it's informational, this is a non-trivial refactoring of code to support that spec 17:34:20 NobodyCam: i'm out beginning this friday until january 17:34:21 devananda: do you have an idea of how to get from current states to new states? 17:34:24 NobodyCam: /me is off dec 21-27 17:34:26 yeah I think that if we could get the state machine in k-1 that would be awesome 17:34:29 rloo: so, I agree - this should all land in kilo-1 if possible 17:34:41 but I haven't looked at the code yet, I will do it asap 17:34:42 * JayF gone all next week 17:34:48 rloo: right now, just an idea, but this refactoring is the beginning of that 17:35:01 so this is the week to land'um 17:35:09 rloo: there's going to be some odd edge cases -- the last patch in the series starts to find them 17:35:15 where drivers are currently manipulating the state directly 17:35:51 rloo: the new state machine is only adding new states, not renaming or removing states 17:36:05 devananda: i spent a good bit of time pulling the fsm code out and playing with it independently to understand how it works. seems pretty sound. 17:36:22 so I think we can migrate, as long as there are no in-progress operations during the migration 17:37:11 but I don't yet have an implementation of the new state machine to migrate to. not sure I'll get to that this week. next week is more likely 17:37:13 devananda: and somehow deal with backwards compatibility :-( 17:37:42 devananda: I think if we can get the current states in an FSM this week, that'd be great ;) 17:37:48 devananda: how large do you think the edge case issue (of drivers changing state directly) is going to be 17:37:49 I don't think backwards compat will be horrible, with us expressing it this way 17:38:00 we'll just have extra states and transitions we're dragging around for a while 17:38:14 rloo: I think "new server, old client" will be relatively easy -- the same three states are present and should be supported requests 17:38:14 oh, out of tree drivers. 17:38:50 jroll: we'll be expressing new states that the older clients dont understand 17:39:07 mmm 17:39:11 jroll: but POST ... {state: } should still work with the old three states 17:39:17 yeah, agree 17:39:21 that's what I'm aiming for 17:39:35 make sure that an older nova.virt.ironic driver still works with a new ironic service 17:39:41 so that operators can upgrade Ironic first, then Nova second 17:40:08 * jroll wonders if he also wants the other direction to work 17:40:33 anyhow. let's not birdwalk too far into that, and instead let's discuss that on the reviews 17:40:42 jroll: please no 17:40:42 yeah 17:40:45 lol 17:41:38 devananda: are you planing on pushing up a new version of 139215 to address rloo comments? 17:41:49 rloo: I'll address your comments on the first patch today 17:41:59 :) 17:42:05 I'd love to get feedback on the rest of the patches this morning so I can try to address all of them this afternoon 17:42:11 thx devananda 17:42:27 in particular, the last two or three 17:42:33 which start to show the ramifications of this change 17:42:42 eg, https://review.openstack.org/#/c/140883/ 17:42:51 * NobodyCam has not gotten that far in the chanin yet :( 17:42:52 and https://review.openstack.org/#/c/140869/4 17:43:32 140883 should be covering all the in-tree drivers 17:43:48 anyone working on a new driver, or maintaining out of tree drivers, is going to want to do similar 17:44:01 it's also very likely I missed some state changes, so that patch may grow 17:44:15 was just grepping ... 17:44:38 its a great start. thank you devananda :) 17:44:53 anyhow, thanks in advance for the reviews. let's move on so we have time for open discussion 17:44:58 #topic open discussion 17:45:21 ok, bugday 17:45:33 or review jam day or whatever 17:45:36 hey guys 17:45:40 lol okay this weekend I started to hack on a PixieBoots Irc bot 17:45:40 Folks, there was a discussion about Fuel Agent driver for Ironic. The spec https://review.openstack.org/#/c/138115/ was updated significantly and now should be much more compliant with what we have in Ironic. Did anyone have a chance to look at it? If so, do you think it’s possible to land this kind of feature to Ironic? 17:45:40 any chance we can do that this week rather than next? 17:45:49 bug day? holiday time? 17:45:50 jroll: heh :) 17:46:05 jroll, I'm good with that, maybe at the end of the week like thursday 17:46:26 thursday works 17:46:26 ++ 17:46:36 rloo: how is thurdday? 17:46:49 jroll: I'd love to see a few of us spend a chunk of time going through the bug list and re-triaging things 17:47:14 Hey guys; I was wondering how much folks would be in favor of a single repository with things needed to build Ironic's various required ramdisks. DIB elements needed for Ironic, the CoreOS ramdisk builder + logic to build IPA would go in there to start 17:47:26 do we need dtantsur fir that 17:47:33 jroll: I'm around Thurs, but if we're still trying to get patches into kilo-1, I'd rather focus on that. 17:47:43 thursday is good for me, though I may be out part of the day 17:47:49 rloo: right, we could do a review day for those 17:47:56 I'm out part of the day on thursday for an appointment 17:47:58 NobodyCam: it'd be good if he's there, yes 17:48:23 JayF: I know you've gotten +1 from a few people on that, I feel like you should just write up a simple spec 17:48:29 jroll: also (question for everyone I think). is it more important to do a bug review or maybe a spec review first? wondering if people are being delayed cuz specs aren't being reviewed fast enough or whatever 17:48:32 jroll: how about a reviewday tomorrow focused on kilo-1 open reviews, and then visit the bug list after kilo-1 is tagged 17:48:34 JayF, I'm good with that too 17:48:43 jroll: so do I :) I wanted to do it this weekend but didn't make the time 17:48:47 JayF: +1 but i'm a bit biased 17:48:47 tho I really would like to see all the ramdisks functionalities merged with IPA 17:48:58 JayF, iLO team will be in favor of that 17:49:03 so we could replace all ramdisks and just use ipa instead 17:49:08 JayF: i'm wondering a few things about that 17:49:09 lucasagomes: I'm not as +1 on that as others are; but I think unifying where things are stored will help us in thinking more creatively about ramdisks 17:49:26 devananda: I'm good til noon or so PST tomorrow, wfm 17:49:38 right, my concern is also having the dib element there 17:49:45 JayF: how will that project be tested in relation to the various projects which contain the build tools? 17:49:51 JayF: will that not mean we are maintaining several out of tree "drivers/elements" for different projects? 17:49:54 because time to time they may change some stuff on the dib elements that might affect the ironic-deploy element 17:50:12 JayF: what will that project look like, as an amalgam of *different* types of scripts? 17:50:30 devananda: how is tripleo-image-elements tested in relation to other projects? 17:51:08 devananda: I forsee something along the lines of tripleo-image-elements .. with DIB elements in one dir and a CoreOS builder in another 17:51:13 JayF: I haven't kept up on changes in their gate structure. NobodyCam, do you know? 17:51:27 I'm also willing to split out the CoreOS builder stuff into a completely separate project that then Ironic/IPA could consume 17:51:44 I have not followed the ci changes no :( maybe adam_g knows? 17:52:04 JayF: then either that repo co-gates with both dib and coreosbuilder, or it does not gate and we trust folks not to break it 17:52:21 I'm generally -1 on more things co-gating 17:52:31 * NobodyCam is not a fan of the latter option 17:52:34 i *think* t-i-e changes are tested with a tripleo devtest run, but IMBW 17:53:16 we did do some co-gating with ironic's devstack job + diskimage-builder (where the deploy-ironic element lives) 17:53:47 devananda: I'm not sure if what I propose is the right solution; but I think it's better (gating issues taken into account as well) than us currently having builders scattered about :/ 17:53:53 let's leave it to the spec process, I think 17:54:03 we're going to forget everything we said here 17:54:27 kozhukalov: I haven't had a chance to look at the new spec version yet. will try to this week, but will be focusing on kilo-1 milestone 17:54:45 speaking of ramdisk, is there any plan to merge PXE ramdisk with IPA ramdiks? 17:54:46 jroll: ++ 17:55:04 *BEEP* five minute bell 17:55:11 wanyen: they serve different use-cases today. so, not in the short term. 17:55:26 I meant add support of iscsi to IPA 17:55:33 wanyen: that said, I think it'd be great if IPA supported the remote-iscsi-attach method as well 17:55:33 wanyen, i'd like to see those merged, but I don't know about anyone who's actually working on it 17:55:48 jroll, JayF: any plans for ^ ? 17:55:49 wrt fuel agent stuff, I still maintain that we can land those features in IPA quickly, but I may be biased etc. idk. going to stay out of it other than pointing this out. 17:55:59 wanyen: devananda: should be pretty easy to do 17:56:04 * JayF == jroll w/r/t fuel agent 17:56:29 jroll, are u plan to do it for kilo? 17:56:34 devananda: someone just needs to take on the work, there's two ways of going about it 17:56:34 remote-iscsi-attach method? 17:56:45 NobodyCam, any news on the DIB element for IPA? 17:56:49 wanyen: I'm not planning on it, I will if nobody else does 17:56:59 lucasagomes: it exists, it works, it also requires 3gb of RAM :( 17:57:06 :O 17:57:11 3gb to build? 17:57:14 jroll: yea, that is fail :( 17:57:15 lucasagomes: I restarted my effort. the original direction was not correct 17:57:21 or the machine needs 3g to boot the ramdisk? 17:57:22 lucasagomes: 3gb to RUN 17:57:24 omg 17:57:27 jroll: devananda: 1) Being hack the ramdisk to start an iscsi target daemon if an option is passed or 2) Give IPA a call to expose disks as an iscsi target 17:57:27 right. 17:57:28 why's that? 17:57:49 lucasagomes: because people didn't spend weeks optimizing it like we did for the coreos image 17:58:01 both options lead to a heavier ramdisk and cause issues in the gate, right? (size of ramdisk is huge) 17:58:16 lucasagomes: JayF quite literally spent weeks making CoreOS small 17:58:17 jroll, I see.. well seems like it's going on the right direction then 17:58:22 it's mostly optmizations left 17:58:23 I had started with a swift-temp-url element this was wrong. The logic reallys needed to be in the incubator scriots them self 17:58:33 devananda: thanx a lot, I really appreciate that, will wait for any news 17:58:47 *Two minutes* 17:59:55 please ping me any functions you think a PixieBoots Irc Bot should have: current code found here: https://github.com/NoBodyCam/PixieBootsIrcBot 17:59:55 Jroll, teh node zapping functions will be implmeneted for both IPA and pxe ramdisk? 18:00:01 Any comments on the Cisco power driver spec would be appricated https://review.openstack.org/#/c/139517/ 18:00:15 wanyen: I don't know, I hope so? 18:00:17 wanyen: some will be in pxe 18:00:27 Time 18:00:28 like, erasing disks i think we can do 18:00:32 so we clearly can't pivot the upstream CI to use anything that requires a 3GB VM to run it ... 18:00:33 joshnang and jroll: that's great! 18:00:40 devananda, yeah :/ 18:00:53 wanyen: we can finish in -ironic 18:00:56 the problem with the default ramdisk is the communication between ironic and the running ramdisk 18:01:01 thank's everyone - we're out of time 18:01:07 thank you all 18:01:08 * lucasagomes goes to the channel 18:01:10 thanks 18:01:11 thanks 18:01:12 reminder - next week's meeting is alternate time! 18:01:17 I have to go to a differnt meeting:( 18:01:25 #endmeeting