17:00:01 <jroll> #startmeeting ironic
17:00:01 <openstack> Meeting started Mon Mar 14 17:00:01 2016 UTC and is due to finish in 60 minutes.  The chair is jroll. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:05 <openstack> The meeting name has been set to 'ironic'
17:00:08 <jroll> #chair devananda NobodyCam
17:00:08 <openstack> Current chairs: NobodyCam devananda jroll
17:00:17 <devananda> o/
17:00:18 <TheJulia> o/
17:00:22 <stendulker> o/
17:00:26 <rpioso> o/
17:00:36 <sambetts> o/
17:00:38 <sinval> o/
17:00:53 <lucasagomes> o/
17:00:59 <vdrok> o/
17:01:11 <dtantsur> o/
17:01:15 <rloo> o/
17:01:19 <thiagop> o/
17:01:20 <jlvillal> \o\  /o/
17:01:21 <Nisha> o/
17:01:25 <krtaylor> o/
17:01:33 <mkovacik> o/
17:01:36 <jroll> hey everyone :)
17:01:44 <jroll> #topic announcements and reminders
17:02:14 <jroll> a few things here
17:02:24 <jroll> I sent an email friday about the rest of the cycle
17:02:26 <jroll> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/089143.html
17:02:43 <jroll> first, as noted in there, we're bumping the networks work to newton
17:02:52 <jroll> huge apologies for that :(
17:03:16 <jroll> there's also a couple notes on things I'd like to finish this cycle, please do reply if you have more
17:03:47 <jroll> so, please do help on those items
17:04:05 <jroll> I've started an etherpad to collect summit session ideas:
17:04:07 <jroll> #link https://etherpad.openstack.org/p/ironic-newton-summit
17:04:13 <jroll> please add your things there
17:04:24 <lucasagomes> nice, thanks
17:04:25 * lucasagomes adds
17:04:30 <jroll> also, I'm running for PTL again for newton
17:04:33 <jroll> please do run against me :D
17:04:38 <dtantsur> :D
17:04:56 <dtantsur> do we want to discuss the driver composition again or should we Just Do It (tm)?
17:04:56 <TheJulia> :)
17:04:58 <jroll> it's been a pleasure working with y'all this cycle, I'll continue to do it in newton whether or not it's as PTL
17:05:30 <rloo> dtantsur: there's a spec for driver composition, right? Just Do It!
17:05:32 <jroll> dtantsur: I have a todo to fix up the spec for that, I can do that this week and then we can see how much we have to argue about? :)
17:05:49 <lucasagomes> dtantsur, I would just do it (I mean, after the spec is merged)
17:05:52 <dtantsur> ack :) then I'm not putting this topic for now
17:06:01 <dtantsur> I hope we can converge on the spec
17:06:13 <jroll> +1
17:07:22 <jroll> ok, any other things here?
17:08:12 <jroll> #topic subteam status reports
17:08:15 <jroll> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:08:20 <jroll> starts at line 101
17:09:18 * jroll gives folks a couple minutes
17:10:58 <jroll> any questions on this stuff?
17:11:03 <dtantsur> while everyone is silent, I'll boast about inspector release :)
17:11:07 <jroll> ++
17:11:17 <rloo> so not directly related to subteam report, but the inspector stuff made me wonder. should we try to land the partition image support for agent drivers in mitaka?
17:11:21 <dtantsur> features a lot of cool stuff, including autodiscovery work by aarefiev
17:11:28 <rloo> dtantsur: ++
17:11:29 <lucasagomes> let's re-review the RAID doc today, that's the last bit missing for RAID
17:11:41 <lucasagomes> and is +2 by rloo already, so it should be pretty good :D
17:11:57 <jroll> rloo: yeah, it's on my list of things we should finish
17:12:06 <jroll> rloo: or are you saying it's late?
17:12:40 <rloo> jroll: well, it is a feature. but i don't recall whether we follow similar 'rules' as other projects.
17:12:40 <lucasagomes> rloo, I think we can try, tho Nisha is having some problems with bios system at present (judging by our conversation on IRC)
17:12:53 <lucasagomes> but if it's sorted I think we should try to have it, it's a nice feature
17:12:58 <jroll> rloo: yeah, not worried about feature freeze, I don't think it's super risky
17:13:24 <rloo> ok then. just wanted to make sure/check. i think we want folks to test what we have now, right?
17:13:32 <dtantsur> inspector freezes a bit earlier cause 1. we've finished all non-risky stuff we were aiming for 2. we usually get less testing
17:13:41 <jroll> I mean, we want people testing everything all the time :)
17:14:11 <rloo> want :)
17:14:12 <lucasagomes> well that said, we don't have a gate job for partition image + agent
17:14:18 <lucasagomes> as well we don't have one for whole disk image + iscsi
17:14:20 <Nisha> rloo, the partition image support works absolutely fine for all combinations except bios + localboot. The image login prompt doesnt come up.
17:14:47 <Nisha> it works for uefi + localboot
17:15:20 <rloo> All I'm asking is whether it is risky to get a feature in, 2 weeks before we make a stable/mitaka cut. I haven't followed this feature so if folks are good with it, that's fine with me :)
17:15:25 <jroll> well, let's keep working on it and get it in
17:15:32 <jroll> I would prefer a gate job
17:15:41 <jroll> but not requiring it to land it
17:15:45 <lucasagomes> ++
17:15:53 <lucasagomes> yeah let's see how it goes
17:15:58 <Nisha> rloo, :) jroll lucasagomes thanks
17:16:04 <dtantsur> in inspector we started creating gate jobs before the feature is implemented
17:16:19 <dtantsur> it's pretty convenient to check that the feature works from day 0
17:16:25 <sambetts> +1
17:16:26 <dtantsur> of course it means that the jobs are non-voting :)
17:16:31 <jroll> dtantsur: yeah, we should strive for that, but I want to refactor our gate a bit first, like we talked about at midcycle
17:16:34 <devananda> dtantsur: ++
17:16:38 <jroll> otherwise we'll have 50 gate jobs :)
17:16:39 <lucasagomes> I agree... tho the partiton vs whole disk image requires some devstack-gate changes
17:16:43 <lucasagomes> which takes ages to merge
17:16:51 <lucasagomes> usually takes*
17:17:12 <jroll> I tend to think some of the d-s-g stuff could move to our devstack plugin
17:17:26 <lucasagomes> jroll, I agree too, or project-config
17:17:32 <jroll> yep
17:18:20 <sambetts> it would be much nicer if the devstack level configs for Ironic where in one place instead of having to grep 3 repos for them :)
17:19:26 <jroll> yeah, agree
17:19:30 <jroll> ok, any other subteam things?
17:20:06 <jroll> #topic Let's use oslo's config generator
17:20:10 <jroll> this is me
17:20:28 <jroll> there was a discussion in the ironic channel about this, maybe 1.5 weeks ago, and it got all contentious
17:20:32 <gabrielbezerra> One more: we from OneView would love to have more reviews on our dynamic allocation spec
17:20:37 <jroll> dhellmann reached out to me to talk about it
17:21:11 <jroll> oslo's config generator gives us quite a few features, and they're planning things like automatic population of the config reference doc
17:21:24 <jroll> #link https://review.openstack.org/#/c/247331/
17:21:30 <NobodyCam> gabrielbezerra: save that for Open Discussion
17:21:32 <jroll> was the most recent rejected patch
17:21:53 <jroll> and I understand there's some objection over the maintenance of all the entrypoints and such
17:21:58 <dtantsur> our experience with oslo-config-generator in inspector is awesome. it really rocks. but we don't have that many config options..
17:22:06 <jroll> lucasagomes and devananda, I believe were the largest voices there
17:22:24 <jroll> and I'd really like to use it, personally
17:22:28 <lucasagomes> jroll, right
17:22:37 <lucasagomes> jroll, I'm not against it now since it has new stuff
17:22:50 <lucasagomes> but before we had no gain in using it vs using that script we do have now
17:23:01 * jlvillal likes the idea as one less thing for us to maintain. Our code currently has no unit tests.
17:23:04 <lucasagomes> it was extra work to maintain that opts.py file that contains all imports
17:23:04 <jroll> ok, cool
17:23:17 <lucasagomes> jroll, looking more into it, different projects have different ways of dealing with oslo.config
17:23:31 <lucasagomes> e.g cinder has a script to generate the opts.py
17:23:33 <rloo> I seem to recall reviewing Ghe's patch and it seemed ugly to me.
17:23:35 <jroll> lucasagomes: yeah, I kind of like nova's thing https://github.com/openstack/nova/tree/master/nova/conf
17:23:54 <jroll> rloo: yeah, that was overboard, lintan's is a bit more sane
17:24:01 <lucasagomes> jroll, right or it can be done as nova, re organizing the opts
17:24:21 <lucasagomes> both requires massive refactors so, I would suggest we do it in newton
17:24:23 <lucasagomes> not this cycle
17:24:47 <devananda> yep. I find the approach of having to list all the entrypoints both cumbersome and error prone. but if we also reorganized all the conf definitions like nova did -- much less of a burden down the road
17:24:47 <jroll> yeah, I'm fine with newton
17:24:58 <devananda> and I'd be fine with that
17:25:22 <jroll> yeah, quite a bit more work
17:25:26 <rloo> I took a quick look at nova's approach and that seems fine to me too, for early newton :)
17:25:34 <jroll> I think I'd like to land lintan's patch first, then work toward re-organizing
17:25:38 <devananda> just stating the obvious, but we need to be sure that, during the change, none of the config options get moved to different option groups
17:25:49 <jroll> heh
17:25:52 <lucasagomes> devananda, ++
17:25:56 <devananda> our gate isn't currently testing all of the options, so something could slip in and break someone downstream
17:26:32 <lucasagomes> fwiw that's how cinder does https://github.com/openstack/cinder/blob/master/cinder/config/generate_cinder_opts.py
17:26:48 <jroll> interesting
17:26:49 <lucasagomes> it auto generates the opts.py to satisfy oslo.config
17:26:59 <lucasagomes> but I prefer nova's approach
17:27:08 * lucasagomes finds oslo.config really ugly
17:27:10 <jroll> agree
17:27:17 <jroll> (with nova comment)
17:27:25 <devananda> lucasagomes: heh, that's interesting
17:27:27 <jroll> I don't love the global CONF thing, otherwise it isn't bad
17:27:33 <lucasagomes> devananda, yeah
17:27:52 <lucasagomes> jroll, we do generate plenty of stuff from code, code docs, api docs etc...
17:28:01 <lucasagomes> I just don't see why we can't do for config but anyway
17:28:05 <lucasagomes> it's water under the bridge
17:28:13 <jroll> lucasagomes: oh, I mean the global CONF object in oslo.config
17:28:18 <lucasagomes> ah right
17:28:46 <jroll> anyway, anybody still against using oslo's config generator?
17:29:13 <jlvillal> Do we wait for Lin Tan's code to merge after Mitaka?
17:29:16 <devananda> fwiw, in looking at these two approaches, I'd prefer we follow the approac nova took. it's declarative and fairly clean. will be easier to maintain than the autogenerate-the-autogenerator approach
17:29:30 <dims> devananda : +1
17:29:30 <lucasagomes> devananda, ++
17:29:32 <rloo> ++ with devananda
17:29:40 <jroll> devananda: yeah, +1
17:29:42 <jroll> jlvillal: yes
17:30:00 <jlvillal> No objection from me. And agree with devananda
17:30:27 <dtantsur> ++
17:30:47 <mgould> ++
17:31:01 <jroll> cool
17:31:20 <jroll> #agreed we will move to oslo config gen in newton, followed by nova-style refactor of config opts
17:31:31 <sambetts> ++
17:31:34 <jroll> #topic open discussion
17:31:39 <jroll> I has nothing here
17:33:02 <dtantsur> I'd love to make more people aware of https://bugs.launchpad.net/ironic-python-agent/+bug/1554492
17:33:02 <openstack> Launchpad bug 1554492 in ironic-python-agent "IPA does not respect the "disk" kernel parameter" [Medium,In progress] - Assigned to Dmitry Tantsur (divius)
17:33:09 <NobodyCam> just rasing gabrielbezerra's question about reviews on https://review.openstack.org/#/c/275726 ... I had given it a second +2 this morning before the meeting
17:33:20 <dtantsur> TL;DR: IPA does not behave exactly the same as the old ramdisk in terms of the default root disk
17:33:24 <dtantsur> and that might break you
17:33:40 <jroll> dtantsur: do you mind emailing -dev and -ops lists?
17:33:41 <lucasagomes> ++ if you have multiple disks ^
17:33:47 <gabrielbezerra> thank you, NobodyCam. I could only see your review now.
17:34:04 <dtantsur> jroll, on my radar, forgot to do it the last week
17:34:05 <gabrielbezerra> I jumped directly into the meeting, before checking e-mails
17:34:09 <jroll> dtantsur: cool, ty
17:34:44 <dtantsur> we'll probably have to carry the patch downstream, until we figure out the migration path...
17:34:58 <jroll> :(
17:35:02 <dtantsur> yep :(
17:35:11 <dtantsur> we should have made root device hints mandatory :D
17:35:22 <lucasagomes> heh
17:35:32 <lucasagomes> we need to improve it first (/me is working on it)
17:35:43 <lucasagomes> it's too rigid now :-( only accepts exact match and such
17:35:46 <lucasagomes> I want to make it more usable
17:35:48 <dtantsur> yeah.. I'd love the default strategy to be configurable too
17:35:51 <lucasagomes> I mean user-friendly
17:35:56 <dtantsur> lucasagomes++
17:35:57 <lucasagomes> dtantsur, indeed
17:36:00 <sambetts> I like the idea of a flag to enable ignoring disk or not
17:36:20 <sambetts> seems like the cleanest compatiblity fix for now
17:36:25 <dtantsur> lets bring it to the ML indeed
17:36:34 <dtantsur> I'll post it tomorrow
17:36:58 <jroll> +1, ty
17:37:00 <devananda> yea, that's going to be challenging. also +1 for making root device hints more user friendly
17:38:17 <lucasagomes> yeah, problem there is most the way we send the hints to the ramdisk
17:38:19 <dtantsur> I would love to get to the point where we can simulate the old behavior with root device hints per node
17:38:29 <lucasagomes> since root device hints is supported by the bash and ipa it uses the kernel cmdline
17:38:31 <dtantsur> aka {"name": ["sda", "hda", "vda"]} or something
17:38:56 <lucasagomes> but that limit us in the syntax we can use (maybe we can json-fy a dict put there but...)
17:38:58 <dtantsur> lucasagomes, bash ramdisk is not supported in newton..
17:39:04 <lucasagomes> dtantsur, exactly
17:39:10 <lucasagomes> so now we can use IPA API's
17:39:23 <lucasagomes> which will give us tons of flexibility on it
17:40:20 <dtantsur> gabrielbezerra, re https://review.openstack.org/#/c/275726: I think we should postpone it until the summit
17:40:35 <dtantsur> there are a lot of people from different vendors doing similar things like hardware pools
17:40:48 <dtantsur> we should make sure we have a consistent inteface for that IMO
17:41:41 * dtantsur is adding a topic to the etherpad
17:42:42 <jroll> alright, anything else folks want to chat about?
17:42:47 <jroll> I could totally use the 15 minutes :)
17:42:48 <gabrielbezerra> I see your point, but our approach in that spec does not change the interface ironic provides. We already have 2 +2s.
17:43:17 <gabrielbezerra> We would love to contribute in such topic in the summit, by the way.
17:43:33 <jroll> let's take that discussion to the spec :)
17:43:57 <sinval> +1
17:44:10 <dtantsur> gabrielbezerra, I just don't want to land this thing, and then e.g. cisco folks to come and do the same thing in a completely different fashion :)
17:44:20 <dtantsur> otherwise no objections
17:44:47 <jroll> alright, I'm going to turn the meeting off, there's the ironic channel and the spec for more discussion :)
17:44:50 <jroll> thanks all
17:44:52 <jroll> #endmeeting