05:01:18 <devananda> #startmeeting ironic
05:01:19 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:01:22 <openstack> The meeting name has been set to 'ironic'
05:01:31 <adam_g> o/
05:01:31 <jroll> \o
05:01:34 <mrda> o/
05:01:37 <devananda> hi folks! this is our first meeting at the alternate time! woo! :)
05:01:44 <rameshg87> o/
05:01:48 <takadayuiko> o/
05:01:53 <Haomeng> o/
05:01:55 <ramineni> ramineni: o/
05:01:55 <lintan> o\
05:01:58 * jroll is not feeling great and may just mostly lurk
05:02:18 <devananda> it's pretty late for me so if I'm slower to type than usual ... that's why
05:02:34 <devananda> but also, welcome to all the folks that I haven't frequently seen in meetings before
05:03:01 <devananda> the agenda is, as always, posted on the wiki
05:03:02 <devananda> #link https://wiki.openstack.org/wiki/Meetings/Ironic
05:03:12 <devananda> #topic announcements
05:03:32 <devananda> first a little one
05:03:38 <devananda> lucas is out on vacation this week
05:03:58 <devananda> so a few things may stall while we wait for him, but mostly, probably not much
05:04:04 <wanyen> hi
05:04:21 <jroll> 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 <devananda> jroll: ok, cool
05:04:54 <devananda> I should probably say things about the mid cycle, but I"m going to save that for open discussion
05:05:10 <devananda> #topic subteam status review
05:05:34 <devananda> this is where we look at the status posted on the WhiteBoard, here
05:05:35 <devananda> #link https://etherpad.openstack.org/p/IronicWhiteBoard
05:06:05 <devananda> I'll give everyone a minute or two to raise comments or concerns
05:06:09 <devananda> (or questions)
05:06:13 <devananda> if there aren't any, we'll move on
05:06:15 <jroll> is this the right place to be pointing out spec updates etc?
05:06:23 <jroll> I feel like reviewers should just notice those
05:06:39 <lintan> Can I add AMT Driver into Drivers section?
05:06:45 <devananda> lintan: please do
05:07:01 <devananda> lintan: also, please add AMT driver information to the wiki page ... /me looks for the link
05:07:26 <devananda> lintan: https://wiki.openstack.org/wiki/Ironic/Drivers
05:07:49 <devananda> 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 <lintan> devananda: I will do this later
05:08:07 <jroll> devananda: I mean on the whiteboard, as a weekly status
05:08:16 <jroll> devananda: is that valuable to folks, do you think?
05:08:19 <devananda> jroll: oh. probably not.
05:08:30 <jroll> ok, thanks :)
05:08:44 * jroll is inclined to clear most of that area
05:08:50 <devananda> jroll: if there are critical specs (like the state machine one) those probably warrant an agenda item of their own
05:08:56 <jroll> +1
05:09:04 <mrda> agreed
05:09:14 <devananda> but individual specs or reviews up there aren't worth calling out -- unless they are, for some reason
05:09:35 <jroll> yep
05:09:46 * jroll makes a note and hopes this to be cleaner next week
05:09:58 <devananda> jroll: so, quick question on IPA
05:10:04 <jroll> (also, if anyone knows a better way to paste from etherpad into vim, formatting-wise, would love to know)
05:10:08 <devananda> jroll: agent_ssh-nv -- is this stable now?
05:10:15 <wanyen> what kind of info should be included in driver status?
05:10:16 <devananda> jroll: :set nopaste
05:10:23 <devananda> er, i mean, :set paste
05:10:38 <jroll> devananda: that still doesn't help as etherpad has no trailing spaces for tabs :)
05:10:39 <jroll> anyway
05:10:53 <jroll> agent_ssh-nv is stable, other than the bugs also affecting the pxe_ssh tests
05:11:05 <devananda> wanyen: stability, status of CI, progress on cycle goals
05:11:11 <jroll> we're hesitant to make it vote with those, as it will just mean more rechecks
05:11:19 <wanyen> deva: gotit.
05:11:44 <devananda> jroll: taht's awesome. also, bugs affecting pxe_ssh? or parallel-nv ?
05:11:51 <adam_g> 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 <jroll> 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 <devananda> jroll: mind adding # info to that line so it gets in the minutes?
05:12:56 <jroll> JayF would know more to be honest
05:13:03 <jroll> devananda: sure, but it's in the status
05:13:09 <jroll> #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 <devananda> jroll: more visibility good :)
05:13:22 <jroll> indeed
05:13:30 <devananda> ok - going to move on now
05:13:35 <devananda> thanks, all for the status updaets
05:13:50 <devananda> #topic Kilo-1 milestone status
05:14:08 <devananda> #link https://launchpad.net/ironic/+milestone/kilo-1
05:14:14 <devananda> and for reference
05:14:16 <devananda> #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule
05:14:51 <devananda> we've got, essentially, this week and a little bit of next week
05:14:56 <devananda> until Kilo-1 milestone
05:15:25 <devananda> 4 BPs implemented so far
05:15:45 <devananda> if a BP is on that page and assigned to up, please update the Delivery status
05:16:04 <mrda> thanks for the reminder devananda
05:16:10 <jroll> 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 <lintan> Yes, AMT Driver need review
05:17:19 <devananda> jroll: would it be a quick discussion here? or something we should revisit tomorrow?
05:17:39 <devananda> lintan: any outstanding questions you have on the review, or you just need more folks to review it?
05:17:42 <wanyen> partition image support for agent driver spec is still under review.
05:18:01 <devananda> mrda: same question for you ^
05:18:07 <jroll> devananda: probably longer, idk, let's see if we have time at the end
05:18:23 <jroll> devananda: I'm also not at 100% right now, tomorrow or later may be better
05:18:28 <devananda> 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 <lintan> devananda: No big question, but I need more folks to review
05:19:05 <wanyen> 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 <devananda> 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 <devananda> wanyen: that'd be great
05:19:39 <jroll> devananda: yep, nova spec is in
05:19:57 <devananda> #info code review for the AMT driver needed: https://review.openstack.org/135184
05:20:05 <jroll> 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 <mrda> 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 <jroll> (that code being nova side)
05:20:46 <devananda> 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 <devananda> 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 <wanyen> 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 <devananda> 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 <devananda> wanyen: I think so ... jroll?
05:23:55 <jroll> devananda, wanyen: we've talked about refactoring partitioning code into a library
05:23:59 <jroll> and yes, that should go in the spec
05:24:32 <wanyen> 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 <devananda> wanyen: ok, sounds like it is worth bumping the spec so it isn't rushed, which is fine
05:25:36 <devananda> 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 <wanyen> Deva- that would be great
05:26:20 <devananda> ok - I think that covers K1 (except for the next topic)
05:26:23 <devananda> any last minute items?
05:26:31 <jroll> I'm good
05:27:12 <lazy_prince> is there any target set for neutron port bonding..?
05:27:22 <devananda> #info partition support in IPA bumped to K2, others on track
05:27:39 <devananda> lazy_prince: do you have a link to the spec?
05:27:48 <jroll> 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 <jroll> lazy_prince: it'll need a spec, though
05:28:05 <jroll> and is clearly not complete
05:28:07 <jroll> :P
05:28:16 <devananda> also, fwiw, neutron spec proposal freeze was today
05:28:23 <lazy_prince> aha okay.
05:28:24 <wanyen> 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 <devananda> so any changes that need to land in neutron will have to wait until next cycle, probably
05:28:36 <jroll> wanyen: that's up to nova, not us
05:29:01 <devananda> 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 <jroll> mrda: fun!
05:30:02 <wanyen> So, so should we still puruse that or go for the althernative to use boolean values
05:30:10 <devananda> wanyen: this one? https://review.openstack.org/#/c/133534/
05:30:28 <wanyen> deva, yes.
05:31:10 <devananda> 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 <devananda> 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 <jroll> wanyen: though it sounds like he might be ok with it, you'll need to answer mikal's questions
05:31:55 <devananda> wanyen: I'll make a note to attend the next one as well
05:31:55 <wanyen> deva; will do.
05:32:05 <wanyen> deav, tx
05:32:11 <devananda> ok, moving on to other topics as we're haf way through now
05:32:16 <wanyen> s/deav/deva
05:32:24 <devananda> #topic new state machine proposal
05:32:39 <jroll> ok, what's blocking this spec at this point?
05:32:39 <devananda> #link https://review.openstack.org/#/c/133828/
05:32:44 <jroll> and what can we do to push it along?
05:33:08 <devananda> I think we've gotten +1's from just about every core on the last few revisions
05:33:28 <devananda> jroll: so, possibly we're all just gun-shy about approving such a large change?
05:33:35 <jroll> I guess?
05:33:41 <devananda> jroll: or the ramifications aren't really clear yet?
05:33:46 <jroll> it wouldn't hurt to flesh out the rest
05:34:02 <jroll> and I think it would be great if a core did that
05:34:10 <devananda> what's on my mind is this
05:34:26 <mrda> It's a big change, I guess if the current ironic operators think *their* use cases are covered...
05:34:27 <jroll> I also think we need to land the fsm branch
05:34:33 <devananda> is this spec describing the _intention_ that we have, or the _implementation_ of a specific change?
05:34:42 <jroll> mmm
05:34:44 * devananda grabs that link
05:35:01 <devananda> #link https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:states,n,z
05:35:11 <devananda> so, background here is
05:35:11 <victor_lowther> I intended it to describe the intention :)
05:35:35 <devananda> 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 <devananda> and I couldn't do that from the code we have today
05:35:48 <devananda> so I started converting it to use a formal state model
05:36:11 <devananda> borrowed the fsm.py module from taskflow (thanks harlowja!) and modified it a bit
05:36:21 <devananda> and came up with that branch that I linked up there
05:36:39 <jroll> right
05:36:51 <jroll> so I think we need to land that
05:37:07 <victor_lowther> ya
05:37:11 <devananda> 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 <devananda> without massively breaking users
05:37:22 <victor_lowther> it is useful by itself.
05:37:32 <jroll> 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 <jroll> and at any rate, who is going to write the rest?
05:38:44 <devananda> 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 <jroll> I'm mostly interested in the backwards compat bit
05:39:00 <jroll> ok, that's fine
05:39:16 <jroll> however, the reason we need this to be done with quickly is that we need to land the *code*
05:39:31 <jroll> so we aren't blocking other code
05:39:40 <jroll> actually, maybe not, we're mostly blocking specs atm
05:39:42 <devananda> to a point, yes
05:39:43 * jroll babbling
05:39:58 <devananda> 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 <devananda> to start using the new state machine
05:40:11 <jroll> awesome
05:40:16 <devananda> and referencing this spec. so I think it is doing that job very well
05:40:28 <devananda> the biggest open question for me is the API semantics
05:40:53 <devananda> not around moving from one state to the next -- that shouldn't change (aside from new state names)
05:40:56 <devananda> but around the metadata
05:41:18 <mrda> devananda: can you elaborate?
05:41:20 <devananda> I think we'll need separate specs for that. like how to describe a RAID that I want built during zapping
05:41:37 <devananda> the API for "go from MANAGED to ZAPPING" is fairly obvious today (at least to me)
05:41:53 <jroll> yeah, those should be with the corresponding specs
05:41:58 <devananda> but not the metadata which informs ironic (and the driver) what to do *during* that phase
05:42:08 <devananda> so yea, we'll need that stuff filled in in add'l specs
05:42:11 <mrda> ok
05:42:16 <mrda> I understand
05:42:16 <jroll> that bit has nothing to do with the state machine
05:42:18 <jroll> cool
05:42:23 <devananda> right
05:42:49 <jroll> 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 <devananda> jroll: ++
05:43:05 <Haomeng> 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 <devananda> victor_lowther: want to do one more update to that effect?
05:43:25 <devananda> Haomeng: can you elaborate?
05:43:38 <wanyen> deva, I think node zapping task meta data should go in node zapping spec
05:43:49 <devananda> wanyen: yes :)
05:43:57 <victor_lowther> devananda: ya, I was planning on roling another update tomorrow morning.
05:44:01 <jroll> Haomeng: as in, call to the driver for that logic?
05:44:12 <jroll> victor_lowther: if you do it during this meeting, we'll land it tonight ;)
05:44:47 <victor_lowther> dunno, that is rather alot of work for 15 minutes before midnight
05:44:50 <jroll> (morning is fine, it's late :P)
05:44:52 <jroll> ya
05:44:57 <devananda> victor_lowther: tomorrow is fine :)
05:45:09 <Haomeng> 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 <Haomeng> jroll: yes, maybe we will add new interface for drivers to handle the node init and clean up event
05:45:45 <Haomeng> devananda: but not sure if it is good idea:)
05:45:55 <jroll> Haomeng: I believe that there is room for this in the states :)
05:46:02 <devananda> Haomeng: there will be the possibility for actions during each state transition
05:46:07 <Haomeng> jroll: ok, cool
05:46:13 <Haomeng> devananda: ok
05:46:15 <victor_lowther> devananda: just to be sure, updates adding notes on where implementation details needed to be fleshed out in other specs,yes?
05:46:31 <jroll> ^ should add an #info for that
05:46:42 <devananda> jroll: ack
05:47:52 <devananda> #info new state machine spec is good-to-go, will land after one more update from victor_lowther
05:48:06 <devananda> #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 <devananda> if that's it, I'll move on
05:49:14 <jroll> +1
05:49:18 <Nisha> devananda, the implementation details for each of the section?
05:49:18 <devananda> #topic node properties and driver capabilities
05:49:43 <devananda> just a quick note that these two tightly-related proposals have been bumped to the "L" cycle
05:50:09 <devananda> #link http://specs.openstack.org/openstack/ironic-specs/specs/backlog/driver-capabilities.html
05:50:10 <jroll> 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 <devananda> #link http://specs.openstack.org/openstack/ironic-specs/specs/backlog/hardware-capabilities.html
05:50:35 <Nisha> devananda, node properties also?
05:50:41 <devananda> Nisha: yes
05:50:51 <Nisha> jroll, ok
05:50:58 <devananda> 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 <devananda> and plan to start the work next cycle
05:51:16 <wanyen> iLO driver plans to auto create node capabilities for some discovered hw proeprties
05:51:48 <Nisha> 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 <Nisha> but node propertie sis independent
05:52:04 <Nisha> s/sis/is
05:52:21 <wanyen> for instance, we want to auto discover supported boot modes and auto create node cpabilities for the dicvoered supported boot modes
05:52:34 <jroll> Nisha: wanyen: any features depending on this work will also need to wait for L
05:52:43 <jroll> (as I understand it)
05:52:49 <devananda> correct
05:53:00 <devananda> we can, and should, plan for it
05:53:14 <wanyen> Deva, I kind of think it's related to hw property instrospection
05:53:41 <devananda> wanyen: I agree. but we have a lot of work to do to realistically solve that
05:54:02 <wanyen> So what I meant is that for nova scheduling related proeprties (just a few simple ones) can still be done.
05:54:08 <devananda> 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 <devananda> wanyen: sure. assuming Nova accepts taht change this cycle :)
05:54:30 <Nisha> as i understand node properties refer to introspection here....or introspection is not being discussed here?
05:54:41 <devananda> Nisha: introspection is separate
05:55:01 <Nisha> ohk , so introspection is still in K
05:55:16 <Nisha> devananda, thanks...i thought introspection is bumped to L
05:55:29 <devananda> we need to move on - time is almost out :)
05:55:37 <devananda> #topic open discussion
05:55:37 <mrda> 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 <wanyen> Nisha, I think we canstill do a few simple hw capabiliteis
05:56:12 <Nisha> wanyen, yes i think as part of iLO implementation...
05:56:12 <wanyen> mrda, yes.
05:56:26 <Nisha> mrda, yes
05:56:32 <devananda> wanyen: Nisha: discovery of node properties (cpu, ram, disk, etc) -- well within reach for Kilo cycle
05:56:33 <mrda> So devananda, can you tell us anything about midcycle?  Do we have firm dates? location? suggested hotels? etc
05:56:37 <sirushti> 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 <lintan> 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 <devananda> mrda: yes! I have confirmation on dates and location
05:56:54 <mrda> wanyen: and Nisha: Happy to talk later about this if it will help
05:56:55 <devananda> mrda: haven't ironed out hotels and whatnot yet
05:57:00 <lintan> Someone could help on this? https://review.openstack.org/#/c/130498/
05:57:07 <Nisha> yes
05:57:16 <wanyen> Deva, for iLO driver we wantt o discover a few more properties more than just cpu, disk and memory
05:57:41 <devananda> mrda: grenoble, france, from Feb 3 - 5
05:58:04 <jroll> lintan: I thought this was supported with neutron :/
05:58:15 <mrda> devananda: cool, now I can ask my 2 bosses if I can go (my employer and my wife :)
05:58:26 <devananda> mrda: lol :)
05:58:37 <wanyen> proeprties taht impact scheduling e.g., support boot mode, secure boot ,..etc to avoid human config errors
05:58:53 <mrda> thanks for organising devananda
05:59:03 <mrda> if you have a suggested hotel, that'd be great too
05:59:05 <devananda> mrda: eh, don't thank me until you see how disorganized I am :p
05:59:05 <jroll> lintan: this works in devstack without isc-dhcp-server, I don't think it's a bug
05:59:17 <lintan> jroll: you mean this is already supported?
05:59:21 <mrda> devananda: remember, I came to Portland :P
05:59:21 <jroll> lintan: yes
05:59:28 <jroll> one second, /me gets a link
05:59:30 <devananda> mrda: I'll send all the infos when I have them
05:59:36 <mrda> thnx
05:59:39 <devananda> mrda: lol! hey, your boss organized that, not me :)
05:59:56 <mrda> and this time around it'll be just you :P
06:00:02 <devananda> mrda: scary, huh?
06:00:08 <lintan> jroll: interesting, I will have a try again
06:00:11 <mrda> :)
06:00:23 <jroll> lintan: is this your commit? it was working as far as I know... https://github.com/openstack/ironic/commit/42f3d52ebbd06e2fb06bfb0fb9aa713cf93389a3
06:00:49 <mrda> I think we're out of time (also noting that midcycle is 55 days away :)
06:00:51 <lintan> jroll: Yes
06:00:57 <Nisha> is it possible to attend it remotely?
06:01:12 <jroll> Nisha: yes, we'll be trying to set something up
06:01:16 <lintan> jroll: this is also need a fix in neutron
06:01:23 <jroll> lintan: it certainly was working before that commit :(
06:01:28 <devananda> 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 <jroll> but yes, we're out of time as mrda pointed out, we should go back to the channel
06:01:39 <devananda> ok folks, we are over time now
06:01:43 <devananda> thanks, everyone!
06:01:45 <jroll> thanks deva \o
06:01:48 <Nisha> :) thats fine devananda
06:01:49 <mrda> thanks devananda
06:01:52 <devananda> #endmeeting