05:01:18 #startmeeting ironic 05:01:19 Meeting started Tue Dec 9 05:01:18 2014 UTC and is due to finish in 60 minutes. The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot. 05:01:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 05:01:22 The meeting name has been set to 'ironic' 05:01:31 o/ 05:01:31 \o 05:01:34 o/ 05:01:37 hi folks! this is our first meeting at the alternate time! woo! :) 05:01:44 o/ 05:01:48 o/ 05:01:53 o/ 05:01:55 ramineni: o/ 05:01:55 o\ 05:01:58 * jroll is not feeling great and may just mostly lurk 05:02:18 it's pretty late for me so if I'm slower to type than usual ... that's why 05:02:34 but also, welcome to all the folks that I haven't frequently seen in meetings before 05:03:01 the agenda is, as always, posted on the wiki 05:03:02 #link https://wiki.openstack.org/wiki/Meetings/Ironic 05:03:12 #topic announcements 05:03:32 first a little one 05:03:38 lucas is out on vacation this week 05:03:58 so a few things may stall while we wait for him, but mostly, probably not much 05:04:04 hi 05:04:21 devananda: yeah, he's been passing off some of the refactoring stuff, so we should be okay 05:04:25 * mrda wishes lucas a nice break 05:04:29 jroll: ok, cool 05:04:54 I should probably say things about the mid cycle, but I"m going to save that for open discussion 05:05:10 #topic subteam status review 05:05:34 this is where we look at the status posted on the WhiteBoard, here 05:05:35 #link https://etherpad.openstack.org/p/IronicWhiteBoard 05:06:05 I'll give everyone a minute or two to raise comments or concerns 05:06:09 (or questions) 05:06:13 if there aren't any, we'll move on 05:06:15 is this the right place to be pointing out spec updates etc? 05:06:23 I feel like reviewers should just notice those 05:06:39 Can I add AMT Driver into Drivers section? 05:06:45 lintan: please do 05:07:01 lintan: also, please add AMT driver information to the wiki page ... /me looks for the link 05:07:26 lintan: https://wiki.openstack.org/wiki/Ironic/Drivers 05:07:49 jroll: this'd be a fine time to do that, sure, though I have a separate agenda item for progress review today 05:08:03 devananda: I will do this later 05:08:07 devananda: I mean on the whiteboard, as a weekly status 05:08:16 devananda: is that valuable to folks, do you think? 05:08:19 jroll: oh. probably not. 05:08:30 ok, thanks :) 05:08:44 * jroll is inclined to clear most of that area 05:08:50 jroll: if there are critical specs (like the state machine one) those probably warrant an agenda item of their own 05:08:56 +1 05:09:04 agreed 05:09:14 but individual specs or reviews up there aren't worth calling out -- unless they are, for some reason 05:09:35 yep 05:09:46 * jroll makes a note and hopes this to be cleaner next week 05:09:58 jroll: so, quick question on IPA 05:10:04 (also, if anyone knows a better way to paste from etherpad into vim, formatting-wise, would love to know) 05:10:08 jroll: agent_ssh-nv -- is this stable now? 05:10:15 what kind of info should be included in driver status? 05:10:16 jroll: :set nopaste 05:10:23 er, i mean, :set paste 05:10:38 devananda: that still doesn't help as etherpad has no trailing spaces for tabs :) 05:10:39 anyway 05:10:53 agent_ssh-nv is stable, other than the bugs also affecting the pxe_ssh tests 05:11:05 wanyen: stability, status of CI, progress on cycle goals 05:11:11 we're hesitant to make it vote with those, as it will just mean more rechecks 05:11:19 deva: gotit. 05:11:44 jroll: taht's awesome. also, bugs affecting pxe_ssh? or parallel-nv ? 05:11:51 the bug affecting the pxe_ssh test is for the parallel variant, which is still -nv. so not a huge deal atm, tho the same bug is hampering forward (j -> k) testing efforts, and i believe agent stuff as well 05:12:20 check-tempest-dsvm-ironic-agent_ssh-nv is still expected to pass on all Ironic changes, even though it doesn't vote, barring bugs #1398128 and #139770 (existing gate bugs) 05:12:49 jroll: mind adding # info to that line so it gets in the minutes? 05:12:56 JayF would know more to be honest 05:13:03 devananda: sure, but it's in the status 05:13:09 #info check-tempest-dsvm-ironic-agent_ssh-nv is still expected to pass on all Ironic changes, even though it doesn't vote, barring bugs #1398128 and #139770 (existing gate bugs) 05:13:18 jroll: more visibility good :) 05:13:22 indeed 05:13:30 ok - going to move on now 05:13:35 thanks, all for the status updaets 05:13:50 #topic Kilo-1 milestone status 05:14:08 #link https://launchpad.net/ironic/+milestone/kilo-1 05:14:14 and for reference 05:14:16 #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule 05:14:51 we've got, essentially, this week and a little bit of next week 05:14:56 until Kilo-1 milestone 05:15:25 4 BPs implemented so far 05:15:45 if a BP is on that page and assigned to up, please update the Delivery status 05:16:04 thanks for the reminder devananda 05:16:10 I notice the configdrive stuff is assigned to me; lucas was going to write the code for the PXE driver, but he's out... I'm tied up in some internal stuff this week but could maybe find time? don't want to make promises. we also need to talk more about how to implement it 05:16:25 Yes, AMT Driver need review 05:17:19 jroll: would it be a quick discussion here? or something we should revisit tomorrow? 05:17:39 lintan: any outstanding questions you have on the review, or you just need more folks to review it? 05:17:42 partition image support for agent driver spec is still under review. 05:18:01 mrda: same question for you ^ 05:18:07 devananda: probably longer, idk, let's see if we have time at the end 05:18:23 devananda: I'm also not at 100% right now, tomorrow or later may be better 05:18:28 wanyen: ah, that's right. do you think there's a chance it'll be done in time, or should we bump it? 05:18:44 devananda: No big question, but I need more folks to review 05:19:05 Let mecheck with faizanand get back to you. He can upload a version soon for review. 05:19:06 * jroll makes a note to review that 05:19:21 jroll: ack. tomorrow is fine. I believe I saw the Nova side of that get ack'd, so let's not let it stall too long even if we have to bump it past next week 05:19:29 wanyen: that'd be great 05:19:39 devananda: yep, nova spec is in 05:19:57 #info code review for the AMT driver needed: https://review.openstack.org/135184 05:20:05 devananda: though I doubt that code will make K1, maybe just best to bump it since we won't have nova support, idk 05:20:14 devananda: So working on logical name implementation, been distracted on other things. Still aiming for K-1 (at least for ironic itself, python-ironicclient might be K-2) 05:20:32 (that code being nova side) 05:20:46 mrda: I think that's fine. thanks for the heads up 05:21:28 * mrda gives himself a kick up the backside 05:21:59 over the next week, please don't hesitate to ping me if you need something answered / facilitated with regard to these blueprints 05:22:06 deva, one thing about partition driver for agent driver. I think jroll suggested code refactor for code sharing. Does that infoneeds to be covered in the spec. I think Faizan spent timeon looking into that. 05:22:25 they're the ones which seem most likely to get in // least dependent upon all the other big changes in the pipe for k2 and k3 05:22:38 wanyen: I think so ... jroll? 05:23:55 devananda, wanyen: we've talked about refactoring partitioning code into a library 05:23:59 and yes, that should go in the spec 05:24:32 deva- that will take more time for the spec. In any rate I will check with Faizan and see if he can include that in the spec soon. 05:25:11 wanyen: ok, sounds like it is worth bumping the spec so it isn't rushed, which is fine 05:25:36 wanyen: I'll retarget that for K2, but would still like to get consensus and land the spec, if possible, by the end of next week 05:25:58 Deva- that would be great 05:26:20 ok - I think that covers K1 (except for the next topic) 05:26:23 any last minute items? 05:26:31 I'm good 05:27:12 is there any target set for neutron port bonding..? 05:27:22 #info partition support in IPA bumped to K2, others on track 05:27:39 lazy_prince: do you have a link to the spec? 05:27:48 lazy_prince: neutron doesn't support that at all today, however I did put up a wip patch for ironic to use our plugin: https://review.openstack.org/#/c/139687/ 05:27:52 lazy_prince: it'll need a spec, though 05:28:05 and is clearly not complete 05:28:07 :P 05:28:16 also, fwiw, neutron spec proposal freeze was today 05:28:23 aha okay. 05:28:24 Deva, we have a spec to make changes to Nova computeCapbilityFilter to support list key values. I felt that we need to target that spec for earlier cycle 05:28:30 so any changes that need to land in neutron will have to wait until next cycle, probably 05:28:36 wanyen: that's up to nova, not us 05:29:01 wanyen: yea, that is Nova's decision, not ours. I believe I saw a spec there, which mikal said was not a priority for them ? 05:29:15 * devananda looks for a link 05:29:21 * mrda notes that Nova specs close on the 18th, and that they are unlikely to accept new work at this stage anyways 05:29:32 mrda: fun! 05:30:02 So, so should we still puruse that or go for the althernative to use boolean values 05:30:10 wanyen: this one? https://review.openstack.org/#/c/133534/ 05:30:28 deva, yes. 05:31:10 wanyen: ok, it looks like it has +2 from john but -1 from mikal, as that isn't a priority for nova 05:31:40 wanyen: if the change is demonstrably small, it might be able to make it in. you should bring it up in the nova meeting 05:31:55 wanyen: though it sounds like he might be ok with it, you'll need to answer mikal's questions 05:31:55 wanyen: I'll make a note to attend the next one as well 05:31:55 deva; will do. 05:32:05 deav, tx 05:32:11 ok, moving on to other topics as we're haf way through now 05:32:16 s/deav/deva 05:32:24 #topic new state machine proposal 05:32:39 ok, what's blocking this spec at this point? 05:32:39 #link https://review.openstack.org/#/c/133828/ 05:32:44 and what can we do to push it along? 05:33:08 I think we've gotten +1's from just about every core on the last few revisions 05:33:28 jroll: so, possibly we're all just gun-shy about approving such a large change? 05:33:35 I guess? 05:33:41 jroll: or the ramifications aren't really clear yet? 05:33:46 it wouldn't hurt to flesh out the rest 05:34:02 and I think it would be great if a core did that 05:34:10 what's on my mind is this 05:34:26 It's a big change, I guess if the current ironic operators think *their* use cases are covered... 05:34:27 I also think we need to land the fsm branch 05:34:33 is this spec describing the _intention_ that we have, or the _implementation_ of a specific change? 05:34:42 mmm 05:34:44 * devananda grabs that link 05:35:01 #link https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:states,n,z 05:35:11 so, background here is 05:35:11 I intended it to describe the intention :) 05:35:35 that I wanted to be able to reason, for myself, about an upgrade path to get to the state model in victor_lowther's proposal 05:35:42 and I couldn't do that from the code we have today 05:35:48 so I started converting it to use a formal state model 05:36:11 borrowed the fsm.py module from taskflow (thanks harlowja!) and modified it a bit 05:36:21 and came up with that branch that I linked up there 05:36:39 right 05:36:51 so I think we need to land that 05:37:07 ya 05:37:11 I haven't started it yet, but I'm fairly confident we can get from that to a formal model that includes all the states in victor_lowther's proposal 05:37:19 without massively breaking users 05:37:22 it is useful by itself. 05:37:32 as far as the spec; do we want to land the existing spec, and work on a new spec to flesh out implementation? or do we want to continue to iterate on this spec 05:38:38 and at any rate, who is going to write the rest? 05:38:44 jroll: I'm good if we update the current spec to (more) clearly state that implementation details will follow, then landing it 05:38:50 I'm mostly interested in the backwards compat bit 05:39:00 ok, that's fine 05:39:16 however, the reason we need this to be done with quickly is that we need to land the *code* 05:39:31 so we aren't blocking other code 05:39:40 actually, maybe not, we're mostly blocking specs atm 05:39:42 to a point, yes 05:39:43 * jroll babbling 05:39:58 but to a point, I've see the majority of other specs, whcih are blocked on this, get updaetd in the past week 05:40:02 to start using the new state machine 05:40:11 awesome 05:40:16 and referencing this spec. so I think it is doing that job very well 05:40:28 the biggest open question for me is the API semantics 05:40:53 not around moving from one state to the next -- that shouldn't change (aside from new state names) 05:40:56 but around the metadata 05:41:18 devananda: can you elaborate? 05:41:20 I think we'll need separate specs for that. like how to describe a RAID that I want built during zapping 05:41:37 the API for "go from MANAGED to ZAPPING" is fairly obvious today (at least to me) 05:41:53 yeah, those should be with the corresponding specs 05:41:58 but not the metadata which informs ironic (and the driver) what to do *during* that phase 05:42:08 so yea, we'll need that stuff filled in in add'l specs 05:42:11 ok 05:42:16 I understand 05:42:16 that bit has nothing to do with the state machine 05:42:18 cool 05:42:23 right 05:42:49 devananda: do we want to have someone fill in "implementation details to follow" on the open sections, and we'll agree to land it tonight or tomorrow? 05:43:00 jroll: ++ 05:43:05 devananda: one question here , can we add some hook method such nova init_host method and clean_up node mehtods for our new state machine to do some logic during node init and clean up? 05:43:20 victor_lowther: want to do one more update to that effect? 05:43:25 Haomeng: can you elaborate? 05:43:38 deva, I think node zapping task meta data should go in node zapping spec 05:43:49 wanyen: yes :) 05:43:57 devananda: ya, I was planning on roling another update tomorrow morning. 05:44:01 Haomeng: as in, call to the driver for that logic? 05:44:12 victor_lowther: if you do it during this meeting, we'll land it tonight ;) 05:44:47 dunno, that is rather alot of work for 15 minutes before midnight 05:44:50 (morning is fine, it's late :P) 05:44:52 ya 05:44:57 victor_lowther: tomorrow is fine :) 05:45:09 devananda: such as during our node is created, if we have init_host method interface which can be called at that time, we can do something for some driver to do some logic to init the node at that time 05:45:36 jroll: yes, maybe we will add new interface for drivers to handle the node init and clean up event 05:45:45 devananda: but not sure if it is good idea:) 05:45:55 Haomeng: I believe that there is room for this in the states :) 05:46:02 Haomeng: there will be the possibility for actions during each state transition 05:46:07 jroll: ok, cool 05:46:13 devananda: ok 05:46:15 devananda: just to be sure, updates adding notes on where implementation details needed to be fleshed out in other specs,yes? 05:46:31 ^ should add an #info for that 05:46:42 jroll: ack 05:47:52 #info new state machine spec is good-to-go, will land after one more update from victor_lowther 05:48:06 #info details of the metadata and interactions around some new state transitions (eg, for building a RAID during ZAPPING) to be fleshed out in their respective specs 05:48:48 if that's it, I'll move on 05:49:14 +1 05:49:18 devananda, the implementation details for each of the section? 05:49:18 #topic node properties and driver capabilities 05:49:43 just a quick note that these two tightly-related proposals have been bumped to the "L" cycle 05:50:09 #link http://specs.openstack.org/openstack/ironic-specs/specs/backlog/driver-capabilities.html 05:50:10 Nisha: the details for things like zapping... there will likely be another state machine spec for the implementation of the state machine specifically 05:50:19 #link http://specs.openstack.org/openstack/ironic-specs/specs/backlog/hardware-capabilities.html 05:50:35 devananda, node properties also? 05:50:41 Nisha: yes 05:50:51 jroll, ok 05:50:58 the authors of each of those agreed that, with the other major work this cycle, it would be better to record the intent in a /backlog/ item 05:51:11 and plan to start the work next cycle 05:51:16 iLO driver plans to auto create node capabilities for some discovered hw proeprties 05:51:48 hardware capabilities is dependent on node properties spec (generic one) 05:51:53 * mrda notes we've only got 9 minutes left in this meeting 05:51:58 but node propertie sis independent 05:52:04 s/sis/is 05:52:21 for instance, we want to auto discover supported boot modes and auto create node cpabilities for the dicvoered supported boot modes 05:52:34 Nisha: wanyen: any features depending on this work will also need to wait for L 05:52:43 (as I understand it) 05:52:49 correct 05:53:00 we can, and should, plan for it 05:53:14 Deva, I kind of think it's related to hw property instrospection 05:53:41 wanyen: I agree. but we have a lot of work to do to realistically solve that 05:54:02 So what I meant is that for nova scheduling related proeprties (just a few simple ones) can still be done. 05:54:08 targeting these for L lets us focus on what we can achieve now and plan for how we'll incorporate additinoal features in four months 05:54:23 wanyen: sure. assuming Nova accepts taht change this cycle :) 05:54:30 as i understand node properties refer to introspection here....or introspection is not being discussed here? 05:54:41 Nisha: introspection is separate 05:55:01 ohk , so introspection is still in K 05:55:16 devananda, thanks...i thought introspection is bumped to L 05:55:29 we need to move on - time is almost out :) 05:55:37 #topic open discussion 05:55:37 wanyen: So i think you need to ensure there is an approved Nova bp for this, and you represent that at a Nova weekly meeting, to get commitment from the Nova team that they will review and merge your code for K. 05:55:42 Nisha, I think we canstill do a few simple hw capabiliteis 05:56:12 wanyen, yes i think as part of iLO implementation... 05:56:12 mrda, yes. 05:56:26 mrda, yes 05:56:32 wanyen: Nisha: discovery of node properties (cpu, ram, disk, etc) -- well within reach for Kilo cycle 05:56:33 So devananda, can you tell us anything about midcycle? Do we have firm dates? location? suggested hotels? etc 05:56:37 Hi, could we come to a conclusion on whole disk image support spec for the PXE driver and get more reviews for it? 05:56:40 I am working on an ipxe bug: https://launchpad.net/bugs/1384577 This need a fix in Neutron, but no cores in neutron care about this�. 05:56:47 mrda: yes! I have confirmation on dates and location 05:56:54 wanyen: and Nisha: Happy to talk later about this if it will help 05:56:55 mrda: haven't ironed out hotels and whatnot yet 05:57:00 Someone could help on this? https://review.openstack.org/#/c/130498/ 05:57:07 yes 05:57:16 Deva, for iLO driver we wantt o discover a few more properties more than just cpu, disk and memory 05:57:41 mrda: grenoble, france, from Feb 3 - 5 05:58:04 lintan: I thought this was supported with neutron :/ 05:58:15 devananda: cool, now I can ask my 2 bosses if I can go (my employer and my wife :) 05:58:26 mrda: lol :) 05:58:37 proeprties taht impact scheduling e.g., support boot mode, secure boot ,..etc to avoid human config errors 05:58:53 thanks for organising devananda 05:59:03 if you have a suggested hotel, that'd be great too 05:59:05 mrda: eh, don't thank me until you see how disorganized I am :p 05:59:05 lintan: this works in devstack without isc-dhcp-server, I don't think it's a bug 05:59:17 jroll: you mean this is already supported? 05:59:21 devananda: remember, I came to Portland :P 05:59:21 lintan: yes 05:59:28 one second, /me gets a link 05:59:30 mrda: I'll send all the infos when I have them 05:59:36 thnx 05:59:39 mrda: lol! hey, your boss organized that, not me :) 05:59:56 and this time around it'll be just you :P 06:00:02 mrda: scary, huh? 06:00:08 jroll: interesting, I will have a try again 06:00:11 :) 06:00:23 lintan: is this your commit? it was working as far as I know... https://github.com/openstack/ironic/commit/42f3d52ebbd06e2fb06bfb0fb9aa713cf93389a3 06:00:49 I think we're out of time (also noting that midcycle is 55 days away :) 06:00:51 jroll: Yes 06:00:57 is it possible to attend it remotely? 06:01:12 Nisha: yes, we'll be trying to set something up 06:01:16 jroll: this is also need a fix in neutron 06:01:23 lintan: it certainly was working before that commit :( 06:01:28 Nisha: we'll try to set up some remote participation, yes, but it'll be our first go at that, so I can't promize what it will look like 06:01:37 but yes, we're out of time as mrda pointed out, we should go back to the channel 06:01:39 ok folks, we are over time now 06:01:43 thanks, everyone! 06:01:45 thanks deva \o 06:01:48 :) thats fine devananda 06:01:49 thanks devananda 06:01:52 #endmeeting