17:00:33 <devananda> #startmeeting ironic
17:00:34 <openstack> Meeting started Mon Feb 23 17:00:33 2015 UTC and is due to finish in 60 minutes.  The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:37 <openstack> The meeting name has been set to 'ironic'
17:00:43 <devananda> hi all!
17:00:44 <dtantsur> \o/
17:00:48 <jroll> hellooo!
17:00:49 <NobodyCam> o/
17:00:50 <Nisha> o/
17:00:53 <stendulker> o/
17:00:55 <naohirot> o/
17:00:55 <lazy_prince> hi all..
17:01:12 <devananda> as usual, our agenda's on the wiki - https://wiki.openstack.org/wiki/Meetings/Ironic
17:01:13 <rloo> hi
17:01:23 <maurosr> hi
17:01:24 <wanyen> o/
17:01:41 <NobodyCam> light agenda today
17:01:54 <JoshNang> o/
17:01:55 <devananda> #topic announcements
17:02:31 <devananda> feature freeze is coming up, and while we got a lot done at the sprints the last few weeks, we've got A TONNE to review ...
17:02:48 <NobodyCam> :)
17:02:51 <dtantsur> oh yeah
17:03:12 <rloo> feature proposal (ie specs) freeze is March 5. Feature freeze (code) is March 19?
17:03:27 <rloo> https://wiki.openstack.org/wiki/Kilo_Release_Schedule
17:03:32 <devananda> rloo: sounds right
17:04:01 <devananda> we're sticking to that, but practically, it means we need to stay on top of our priorities
17:04:04 <devananda> which brings me to
17:04:10 <devananda> last week I was pretty sick and was only sort of here for the meeting
17:04:40 <devananda> at the SF meetup, we talked about how we're tracking our priorities
17:04:48 <NobodyCam> :) /me hopes deva is feeling better
17:04:55 * dtantsur too
17:04:59 * BadCub_ too
17:05:02 <devananda> and BadCub_ volunteered to help me - mostly to help around communicating and keeping launchpad up to date
17:05:14 <devananda> since I don't check on it often enough
17:05:23 <devananda> so I wanted to (re)announce that :)
17:05:32 <devananda> that's all from me - any other announces?
17:05:32 <NobodyCam> :) Thank you BadCub_ :)
17:05:45 * BadCub_ will be digging deeper into that this week :-)
17:06:09 <devananda> ok - moving on
17:06:13 <devananda> #topic status report
17:06:19 <wanyen> deva, some of the approved specs are not on kilo3 launchpad yet
17:06:47 <devananda> wanyen: yes, BadCub_ is aware. please ping him (after the meeting) to update those
17:06:47 <NobodyCam> wanyen: can we #link thouse to BadCub_
17:07:00 <wanyen> will do
17:07:44 <NobodyCam> #link https://etherpad.openstack.org/p/IronicWhiteBoard <- for status reports
17:08:11 <devananda> jroll, JayF: quick update on IPA - I was at the tripleo sprint for a couple days last week, and hope that I made it clear we're switching to IPA
17:08:25 <devananda> the only blocker for them was iSCSI-based deploy support
17:08:45 <devananda> I think ya'll were working with lucas on that -- so if/when that lands, let's make sure to let #tripleo folks know
17:08:51 <jroll> devananda: that's almost done afaik, lucas has been working on it
17:08:52 <NobodyCam> which lucas has been working on
17:08:56 <jroll> that's part of the switch to IPA
17:08:57 <jroll> ok
17:09:01 <devananda> yea
17:09:15 <jroll> we aren't switching without that, so it's not really a blocker
17:09:34 <devananda> i mean that is what blocked tripleo from switching
17:09:47 <lucasagomes> o/
17:09:53 <jlvillal> o/
17:09:57 <jroll> #link https://review.openstack.org/#/c/155727/
17:10:05 <dtantsur> lucasagomes, we've assigned everything to you, thanks
17:10:07 <jroll> iscsi/ipa review ^
17:10:09 <devananda> lucasagomes: ohhai! I was just talking about adding iSCSI support to IPA
17:10:21 <NobodyCam> lucasagomes: how is the iscsi support for IPa going?
17:10:25 <lucasagomes> sorry I'm late, was looking into a problem here
17:10:36 <lucasagomes> NobodyCam, devananda jroll so it works :) but we need to bump the memory on gate
17:10:48 <jroll> ya
17:10:51 * jroll reviews
17:11:00 <devananda> lucasagomes: ah right. in the tempest serial job
17:11:01 <NobodyCam> lucasagomes: what do we need to bump to
17:11:03 <lucasagomes> there's only on problem, as we are using the same PXE config file for both IPA and normal ramdisk
17:11:14 <lucasagomes> I had to remove the rootfstype=ramfs from the PXE
17:11:24 <devananda> lucasagomes: that puts us in a pickle -- we'll have to have support for DIB for the tempest parallel job, then
17:11:26 <lucasagomes> but that makes it use tempfs and the default ramdisk will need more ram too :(
17:11:43 <lucasagomes> devananda, yeah, I was thinking about passing that option to the parallel job
17:11:50 <lucasagomes> as append_pxe_config_option
17:12:00 <lucasagomes> and document that the it can be done for the bash ramdisk
17:12:10 <lucasagomes> devananda, and run the parallel job with the bash ramdisk
17:12:36 <jroll> seems reasonable to me
17:12:53 <naohirot> I'd like to know core team's status of iRMC review, https://review.openstack.org/#/c/146803/ and https://review.openstack.org/#/c/134865/
17:13:02 <devananda> still bothers me that we don't have a means to drop support for the bash ramdisk if we keep the parallel job
17:13:20 <devananda> but let's do it, because we already test both, and this is still better
17:13:24 <lucasagomes> devananda, yeah :/ I don't have a solution for that, it have to go to infra
17:13:41 <devananda> BadCub_: can you add naohirot's links there to the hey-lets-get-some-reviews list?
17:13:43 <wanyen> is there any plan to add ubuntu support for ipa dib element
17:14:06 <jroll> wanyen: I believe (but may be wrong) that the goal is to drop DIB
17:14:19 <lucasagomes> wanyen, not from me, but IPA is just a service like any other. It could be added
17:14:27 <lucasagomes> jroll, I'm not assuming that, not yet at least
17:14:31 <naohirot> devananda: both updated more than 20 times each and there is no issue to be discussed remained.
17:14:39 <jroll> lucasagomes: maybe that's just my goal :)
17:14:55 <lucasagomes> jroll, heh yeah, I mean, the tool that builds the ramdisk is at the end not very relevant for us
17:14:57 <devananda> jroll: we're not necessarily dropping DIB itself - just its init-style ramdisk
17:15:04 <jroll> right, right
17:15:06 <devananda> jroll: there are still folks who care about DIB as a tool
17:15:18 <devananda> and folks care about using iSCSi as a deploy mechanism.
17:15:33 <jroll> right, ok
17:15:35 <lucasagomes> dtantsur, lol just read ur message now. Oh noes everything is too much :)
17:15:53 * jroll digresses
17:15:59 <lucasagomes> devananda, just a point here
17:16:05 <lucasagomes> we still using ISCSI with IPA
17:16:31 <lucasagomes> I think that's important because that's the only way to deploy without using swift
17:16:39 <lucasagomes> so it should continue
17:16:45 <devananda> lucasagomes: yes
17:16:45 <lucasagomes> IMHO
17:16:49 <NobodyCam> yes
17:17:02 <jroll> totally agree
17:17:14 <devananda> lucasagomes: oh, we are definitley NOT removing the iscsi-based deploy mechanism
17:17:25 <lucasagomes> cool :) just making sure
17:17:32 <devananda> if i wasn't clear, I'll restate
17:17:47 <devananda> we need the iSCSI-based deploy as one option, and the fetch-from-swift as another
17:17:53 <lucasagomes> +1
17:17:57 <NobodyCam> :)
17:18:06 <devananda> there are users/operators who want to use coreos to build the ramdisk, and others who want to use DIB
17:18:06 <Nisha> NobodyCam, devananda so if any changes required in DIB for any ironic features they will be considered/supported?
17:18:09 <lucasagomes> so yeah, I have to rebase the patchs in Ironic for IPA. It's now failing gate due the memory problem I pointed
17:18:12 <devananda> we should allow both to continue
17:18:40 <lucasagomes> but should be good. We need this merged: /me getting the link
17:18:43 <devananda> however - the particular "init" style ramdisk which is built by diskimage-builder/ramdisk-image-create -- no one has any particular feelings for that _tool_
17:18:59 <lucasagomes> #link https://review.openstack.org/#/c/158251/
17:19:12 <devananda> Nisha: that's very vague. can you be more specific?
17:19:43 <NobodyCam> BadCub_: please add lucasagomes' link to the list too :)
17:20:03 <BadCub_> NobodyCam will do!
17:20:03 <Nisha> devananda, like for secure boot it requires changes in DIB to build signed iso and images
17:20:10 <stendulker> devananda: There are DIB changes required to iso element in DIB to support secure boot. Would that be upported?
17:20:12 <devananda> lucasagomes: ack, ty. I'll look later. would also like to get adam_g to weigh in on that
17:20:30 <lucasagomes> devananda, cool yeah I've added u and adam_g to the reviewer list
17:20:32 <jroll> this is going fairly off-topic, but as a note, if we can figure out a good way to pass an authenticated glance URL to the agent, we could consider dropping iscsi deploys (not sure what other implications there may be)
17:20:55 <devananda> Nisha: signed instance image? or signed deploy image?
17:21:08 <devananda> jroll: nope. we need to keep iscsi-based deploys.
17:21:14 <lucasagomes> jroll, keystone v3 trusts
17:21:15 <Nisha> signed deploy iso
17:21:15 <stendulker> devananda: Signed instance images
17:21:16 <devananda> jroll: that's waaay off topic, btw
17:21:26 <devananda> Nisha: stendulker: which is it? :)
17:21:28 <lucasagomes> jroll, but also we are making glance optional by only requiring a http url
17:21:33 <lucasagomes> so that would do that too
17:21:43 <jroll> devananda: I know it's off topic, let's talk later; just thinking out loud
17:21:49 <stendulker> devananda: https://review.openstack.org/#/c/153987/
17:22:00 <devananda> Nisha: stendulker: also I did not say anything about dropping DIB support, so I dont understand why you're both asking this
17:22:17 <dtantsur> let's not go too off-topic, we're still in subteam reports
17:22:24 <devananda> yea ...
17:22:31 <devananda> and we're over our 10 minute cap for that
17:22:43 <devananda> also, it didn't seem like we actually had any subteam reports. *shrug*
17:22:50 <stendulker> devananda: We felt its support getting dropped... my mistake.
17:23:01 <devananda> #topic K3 priorities
17:23:16 <devananda> who put this on the agenda? there's no name or link ...
17:23:27 <NobodyCam> oh sorry that was me
17:23:32 <NobodyCam> just before the meeting
17:23:39 <devananda> I mean, we should talk about it, but I wasn't prepared
17:23:47 <wanyen> deva, I addded iLO driver status
17:23:47 <jroll> it was last minute
17:23:48 <NobodyCam> nor I
17:23:49 <devananda> NobodyCam: oh you ninja'd it :p
17:23:52 <jroll> we can punt on it
17:24:02 <devananda> #undo
17:24:03 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x2db4310>
17:24:08 <NobodyCam> I would like to take about open spec reviews
17:24:10 <devananda> #topic chassis discovery tool
17:24:12 <rloo> I wanted to know if there were any specs that were K3 priorities, to get approved before the deadline
17:24:13 <jroll> I just think from now til end of cycle we should cover priorities and see where we're at
17:24:32 <devananda> let's honor the meeting format
17:24:38 <devananda> and get to K3 priorities at the end
17:24:42 <NobodyCam> lol we can come back to that in OD
17:24:45 <devananda> sandhya: hi!
17:24:57 <sandhya> hi devananda...
17:25:23 <devananda> sandhya: do you have a summary prepared?
17:25:37 <devananda> sandhya: if not, I can try to type fast
17:25:44 <sandhya> I added the chassis discovery tool blueprint discussion to
17:25:49 <NobodyCam> #link https://review.openstack.org/#/c/134866/
17:26:20 <sandhya> The blueprint started with a plan initially. And then certain complexities came forth and we decided to do it as a tool
17:26:31 <devananda> I like the tool approach
17:26:45 <dtantsur> ... in it's own repo
17:26:49 <devananda> but I think we need a separate directory for vendor contributed tools
17:27:02 <devananda> dtantsur: actually, no
17:27:07 <lazy_prince> so separate dir or repo..?
17:27:18 <lucasagomes> I think I'm fine with any, but we need to extend the test support to tools/
17:27:25 <lucasagomes> we can't run unittests on that dir in the moment
17:27:27 <devananda> from a packager's perspective, it's going to be awkward if all the tools are in one (or more) separate projects
17:27:34 <lucasagomes> we need some plumbing
17:27:44 <devananda> lucasagomes: right. and tools/* is currently for our project mgmt tooling
17:27:49 <devananda> like building config files and such
17:27:50 <dtantsur> from a packager perspective we need a proper CLI installed by setup.py
17:27:51 <lucasagomes> yes
17:27:53 <devananda> i'd rather put it in contrib/
17:27:56 <devananda> which we dn't have
17:28:02 <devananda> dtantsur: yup
17:28:02 <NobodyCam> lucasagomes: I'm not sure we can test all of these types of tools
17:28:13 <NobodyCam> we could do unittest
17:28:19 <sandhya> So we create a ironic/contrib dir
17:28:20 <lucasagomes> yeah, maybe adding a new dir which we could run unittests agains the scripts in the new dir
17:28:23 <lucasagomes> that would be fine
17:28:25 <devananda> dtantsur: except not everyone will want them
17:28:26 <lazy_prince> so shall we create it and try pushing our patch there..?
17:28:33 <jroll> I'm skeptical that we want user-contributed scripts packaged in distros, idk
17:28:40 <dtantsur> devananda, we won't for example
17:28:43 <devananda> dtantsur: and upstream doesn't claim the're supported or tested -- because, frankly, we can't
17:28:44 <lucasagomes> NobodyCam, I see, maybe not all. But, the chassis one is a python script right?
17:28:54 <lucasagomes> NobodyCam, we should have some test for it
17:29:01 <jroll> let's be concrete and think about what other tools might end up in there... deployment tools? management tools? etc
17:29:10 <dtantsur> devananda, why are we adding it then? what prevents us from having it separately?
17:29:15 <NobodyCam> lucasagomes: yes but requires hardware to support it
17:29:23 <devananda> dtantsur: for non-default, not-everyone-wants-them pyhton scripts, what's wrong with contrib/* and NOT having them installed on the system?
17:29:27 <lucasagomes> NobodyCam, not for unittests
17:29:34 <dtantsur> and not putting even more reviews of unknown stuff on folks?
17:29:41 <devananda> jroll: tools for chassis discovery of different kinds of hardware
17:29:45 <NobodyCam> lucasagomes: ++ very true!
17:29:50 <dtantsur> devananda, we have to review thing we don't understand and don't care about
17:29:54 <devananda> jroll: tools for automating some operations that aren't part of our standard
17:30:05 <dtantsur> (we = some subset of core team)
17:30:21 <jroll> right, ok.
17:30:22 <devananda> dtantsur: well. nothing prevents anyone from putting up a separate repo with their tooling in it today
17:30:47 <dtantsur> devananda, that's what I did for ironic-discoverd, and that's why I feel strange now
17:30:48 <devananda> dtantsur: for some reason, sandhya &co want it to be in the main repo. propbably because they think it'll be easier for users to find it that way
17:31:25 <dtantsur> oh yeah, people read stackforge like "experimental, unsupported and not Official OpenStack (tm)"
17:31:38 <NobodyCam> I am in favor of a contrib type folder, if for nothing more that they make great examples of how people are using ironic
17:31:54 <devananda> dtantsur: I know ... and I want to move discoverd off of stackforge as soon as reasonably possible
17:31:56 <dtantsur> devananda, but I believe if we bring it under openstack/ namespace and mention it in docs, people will easily discover them
17:32:00 <rloo> devananda: do you think that anything that goes in the proposed /contrib need to be reviewed like the rest of the ironic code?
17:32:11 <NobodyCam> thou I do agree that unit tests should be enabled
17:32:12 <dtantsur> devananda, I'm ready at any moment (and I wanted to talk to you about it)
17:32:14 <dtantsur> :)
17:32:23 <devananda> dtantsur: the difference being discoverd should be official, supported, tested in the gate, and is widely applicable
17:32:36 <devananda> dtantsur: this, on the other hand, is a vendor-contributed tool for a very narrow set of users
17:32:42 <devananda> and not testable i nthe gate
17:32:47 <jroll> it makes me sad that people won't use things just because it's in stackforge :(
17:32:48 <devananda> (aside from unit tests)
17:32:53 <devananda> jroll: ++ me too
17:33:05 <dtantsur> jroll, I have problems even here at RH :(
17:33:10 <jroll> ugh
17:33:12 <devananda> dtantsur: that's really sad :(
17:33:26 <devananda> dtantsur: fwiw, I'm constantly telling people about discoverd
17:33:29 <lucasagomes> yeah, it's def a big misconception about it
17:33:33 <dtantsur> oh thanks
17:33:36 <lazy_prince> if unittests are the only concerns, we can put that as part of the patch being proposed too..We can add unittests as well for the tool...
17:33:40 <sandhya> Yes. Unit tests will be enabled. A fake discovery driver that can be plugged in for the tool to run.
17:33:44 <jlvillal> So contrib/XXXXX/some_file.py    Should there be an XXXXXX and if so, would need a naming convention.
17:34:33 <jroll> random thought: would this fit into discoverd?
17:34:35 * jroll ducks
17:34:39 <dtantsur> contrib/ sounds a tiny bit better, though I still won't feel easy approving changes
17:34:41 <NobodyCam> jlvillal: are you thinking XXXXX is per vendor?
17:34:52 <lazy_prince> jlvillal: so you mean a spec for the naming convention..
17:34:54 <dtantsur> jroll, I don't have vendor drivers there for now :)
17:34:55 <jlvillal> NobodyCam: That was my first thought.  But not sure.
17:35:03 <jroll> NobodyCam: let's *not* put vendor names in our repo :/
17:35:16 <jroll> I never want "rackspace" to show up in the ironic tree
17:35:16 <NobodyCam> that what I was thinking
17:35:23 * 43UABVQBF wonders why do we have chassis concept in Ironic
17:35:33 <dtantsur> good question arrived ^^^
17:35:38 <devananda> heh yea
17:35:43 <lucasagomes> 43UABVQBF, to group nodes, but yeah we are not actually using it very well yet
17:35:45 <devananda> I've been suggesting we remove it for >6mo
17:35:49 <jroll> I've heard it's useful for blades as well
17:35:52 <43UABVQBF> lucasagomes: it was me
17:35:57 <jroll> I'd be fine with removing it
17:36:01 <devananda> 43UABVQBF: who's you?
17:36:06 <43UABVQBF> oh it's me rameshg87. for some reason name is not coming
17:36:11 <lucasagomes> lol
17:36:12 <jroll> heh
17:36:13 <devananda> heh
17:36:14 <dtantsur> wow
17:36:16 <NobodyCam> ahh
17:36:17 <devananda> hi ramesh :)
17:36:27 <43UABVQBF> hello devananda :)
17:36:33 <devananda> so, I'd _love_ to remove chassis entirely from ironic
17:36:45 <devananda> however we need to provide some mechanism to group nodes
17:36:51 <devananda> and no one's done that work yet
17:36:53 <jroll> ... do we? why?
17:37:02 <lucasagomes> yeah why? I mean I would rather extend it's use
17:37:02 <dtantsur> what about having tags?
17:37:09 <devananda> dtantsur: ++
17:37:19 <devananda> we're also now pretty far off topic
17:37:22 <jroll> node.extra works well for us to do things like "which rack is this in"
17:37:24 <dtantsur> oh yeah
17:37:32 <devananda> so back to topic
17:37:42 <devananda> I'll summarize
17:37:54 <devananda> - we have the concept of chassis in tree today, but aren't actually using it anywhere
17:38:18 <NobodyCam> this tool can / will make use of this concept
17:38:39 <dtantsur> people will beat me up now, but can we bump it to L? with the decision of whether we're dropping chassis or not...
17:38:40 <devananda> what NobodyCam said :)
17:38:40 <NobodyCam> I like the idea of a contrib folder
17:39:05 <devananda> - we don't have a designated place for vendors, or anyone else ,to contribute "useful" tools
17:39:08 <NobodyCam> The concern I do have is ATC statuc for it
17:39:13 <devananda> (for some definition of useful that is not clear)
17:39:33 <NobodyCam> I would like to exclude atc status for that folder.. .if such could be done
17:39:43 <devananda> NobodyCam: interesting. so if we put it in a repo on stackforge, AND said that repo is part of ironic, the net effect is the same
17:39:49 <devananda> NobodyCam: nope. can't be done
17:39:58 <NobodyCam> ahh
17:40:04 <jroll> do we actually care about atc status things? :|
17:40:07 <devananda> NobodyCam: th eonly way to do that is to push it to stackforge and NOT say it is part of hte ironic project
17:40:18 <dtantsur> my concern is review throughput
17:40:21 <devananda> jroll: I do. but I also think this _should_ grant ATC status.
17:40:28 <NobodyCam> which would MORE harmfull imho
17:40:31 <rloo> ++ with dtantsur
17:40:33 <jroll> huh, ok
17:40:47 <devananda> this is clearly coming from a team of people who use and contribute regularly to ironic
17:40:51 * naohirot what is ATC?
17:40:54 <dtantsur> I'm afraid of getting more and more reviews of stuff I don't remotely understand...
17:40:55 <devananda> why on earth would we want to exclude that from ATC?
17:41:08 <devananda> naohirot: active technical contributor. it means you have voting rights in elections and a free pass t othe design summit
17:41:13 <lucasagomes> naohirot, active technical contributor
17:41:20 <NobodyCam> :-p
17:41:24 <naohirot> thanks :)
17:41:30 <devananda> dtantsur: ahhh. so we need to trust driver authors to know their own code
17:41:39 <devananda> dtantsur: and driver authors need to start ponying up third-party CI
17:42:05 <devananda> dtantsur: if the core team doesn't trust driver authors, we have huge problems as a community
17:42:15 <rloo> devananda: so if we trust driver authors to know their own code, there isn't any need to review their patches?
17:42:16 <NobodyCam> devananda: ++
17:42:19 <dtantsur> devananda, if we don't really review it, what's the use of having in-tree?
17:42:31 <devananda> dtantsur: also we're absolutely going to get more drivers being contributed for hardware that none of us remotely understand
17:42:32 <lucasagomes> yeah, we still have to review it for code styles etc
17:42:35 <devananda> like Cray supercomputers
17:42:51 <dtantsur> devananda, drivers are necessary evil IMO
17:42:57 <jroll> lucasagomes: that's a job for computers :/
17:43:07 <devananda> dtantsur: they're not evil. they are the reason I'm working on this
17:43:13 <lucasagomes> jroll, we can add a lot of hacking rules :D
17:43:18 <NobodyCam> my understanding is that reviews for this folder would have a less strick review criteria
17:43:34 <rameshg87_> vendors can abstract most of their hardware related stuff in their own module and leave little to ironic
17:43:39 <lucasagomes> I mean, we still have to look at the code, idk, I don't wanna blind merge it. I want to see if there's something malicious
17:43:44 <dtantsur> rameshg87_, ++
17:43:47 <lucasagomes> or a dependncy on a non f/oss tool
17:43:54 <sandhya> The tool will be generic. I can probably push the code for it. It will have a base discovery class that can be implemented by drivers.
17:44:02 <devananda> lucasagomes: right
17:44:08 <jroll> whoa
17:44:17 <dtantsur> sandhya, which drivers? I don't see real opportunity for now (maybe FUJITSU?)
17:44:21 <devananda> sandhya: eh?
17:44:27 <jroll> now we're talking about a contrib plugin framework?
17:44:27 <jroll> whoaaa.
17:44:36 <dtantsur> no frameworks please
17:44:41 * devananda is in the whooooaa boat with jroll
17:44:55 <dtantsur> if we're going to have plugins for contrib tools, we'd go insane soon
17:45:00 <jroll> this screams separate repo to me at this point
17:45:08 <lucasagomes> yeah for a generic thing
17:45:13 <lucasagomes> either driver vendor passthru
17:45:18 <lucasagomes> since it already abstract it per driver
17:45:22 <dtantsur> if we're talking about a generic mechanism, let's introduce an API in L cycle (or vendor passthru now)
17:45:22 <lucasagomes> or a separated repo
17:45:31 <devananda> sandhya: if you're going to make it general enough to have a plugin framework for additional drivers, it's really much more than I had thought
17:45:55 <NobodyCam> wait is this a simple tool or a framwork.
17:46:01 <devananda> I need to time box this discussion
17:46:01 <lucasagomes> devananda, driver vendor passthru? It's already kinda like a abstraction for driver specific code
17:46:09 <lazy_prince> its a framework..
17:46:09 <devananda> since we have 15 minutes left and two more large topics
17:46:14 * dtantsur votes for vendor passthru
17:46:29 <lucasagomes> ok move on then
17:46:31 * jroll votes for voting on gerrit
17:46:37 <lucasagomes> jroll, +1
17:46:42 <NobodyCam> lucasagomes: devananda: ++ move on and come back
17:46:43 <devananda> #action devananda to re-review the chassis discovery tool code in depth
17:46:50 <sandhya> Yes, it is a generic framework. I will push the code...
17:46:59 <devananda> sandhya: thanks. I'll take a look today
17:47:02 <lazy_prince> will vendor passthrough let mw enroll a new server in ironic.. if so, we will look into it and come-back...
17:47:11 <devananda> #topic passing capabilities from nova to ironic
17:47:16 <rameshg87_> i am here
17:47:18 <rameshg87_> this is regarding how capabilities can be passed to Ironic with the current changes in nova that got recently merged
17:47:21 <rameshg87_> i know this has been discussed many times in last week, and hardware/driver capabilities will be attempted in a better way in L release
17:47:27 <rameshg87_> this is just a proposal on how it can be done for kilo with the nova patch that got merged with minimal/no changes
17:47:31 <rameshg87_> i have put up a small spec for it - https://review.openstack.org/#/c/158243/
17:47:35 <rameshg87_> we may ask deployers to configure and use the capabilities in the way mentioned in the spec for K release
17:47:38 <rameshg87_> all please have a look at spec
17:47:48 <NobodyCam> #link https://review.openstack.org/#/c/158243
17:47:52 <rameshg87_> mainly wanted to bring out this much. ready to take more questions :)
17:48:11 * lucasagomes adds to his todo list
17:48:20 <devananda> rameshg87_: iiuc, we had originally approved a spec whereby nova would pass only a small set of rules to ironic, but then the code which landed in nova passes EVERYTHING down
17:48:31 <devananda> rameshg87_: so now ironic has to take on the responsibility of parsing that
17:48:34 <devananda> rameshg87_: is that correct?
17:48:35 <rameshg87_> devananda: yeah.
17:48:40 <rloo> wondering why this spec isn't a developer doc
17:48:41 <Nisha> devananda, yes
17:48:46 <NobodyCam> rameshg87_: do you have the link to the nova spec that landed
17:48:48 <rameshg87_> devananda: but in my opinion ironic doesn't need to actually care about parsing everything
17:48:57 <devananda> rameshg87_: ok, i see
17:48:59 <rameshg87_> NobodyCam: it's within the ironic spec
17:49:06 <rameshg87_> devananda: i have put out my reasons in the spec.
17:49:07 <NobodyCam> ack
17:49:19 <devananda> #link https://review.openstack.org/#/c/141012/
17:49:25 <devananda> that's the nova code which landed
17:49:29 <rameshg87_> devananda: it is more of an agreement from ironic on how they can make use of capabilities for scheduling with the changing in K release
17:49:40 <NobodyCam> thank you devananda :)
17:49:41 <devananda> rameshg87_: great, thanks for bringing it up!
17:49:50 <jroll> rloo: I think turning this into a dev doc might be the goal
17:50:11 <NobodyCam> *10 minutes*
17:50:12 <devananda> ok, moving on
17:50:18 <rameshg87_> yeah, i would contents of this spec will land into docs
17:50:23 <devananda> #topic K3 priorities
17:50:57 <devananda> first off, I know that LP doesn't match the list of approved specs
17:51:10 <devananda> BadCub_ and I will sort that out soon (today I hope)
17:51:17 <NobodyCam> Not to bring it up as a topic now. but I would folks to think about maybe moving the FF deadline up next cycle
17:51:29 <devananda> NobodyCam: yea... I agree
17:51:46 <devananda> I'll bring that up with ttx at the summit (and he'll probably see the ping here too)
17:51:54 <NobodyCam> :)
17:51:55 <devananda> as a suggestion for the general timeline
17:51:56 <dtantsur> proposal freeze or feature freeze?
17:52:08 <dtantsur> (I would like the former to be moved)
17:52:13 <BadCub_> devananda that sounds good
17:52:23 <rloo> if the latter is moved, the former should probably be too
17:52:38 <NobodyCam> dtantsur: maybe both. but I see PF for sure
17:52:40 <devananda> proposal freeze definitely should be sooner, like K2
17:52:52 <devananda> so a question for everyone
17:52:56 <NobodyCam> devananda: ++
17:53:02 <devananda> last cycle, I used a google spreadsheet towards the end of the cycle
17:53:11 <devananda> to coordinate what we were reviewing
17:53:15 <devananda> how'd that work? should I do that again?
17:53:15 <jroll> my two cents: code freezes make me sad
17:53:18 <NobodyCam> #link https://docs.google.com/spreadsheets/d/1Hxyfy60hN_Fit0b-plsPzK6yW3ePQC5IfwuzJwltlbo/edit#gid=1604970109
17:53:37 <NobodyCam> devananda: ++ it worked for me...
17:53:41 <devananda> jroll: coordinated release makes me sad
17:53:45 <dtantsur> worked for me too
17:53:48 <jroll> devananda: ++
17:54:04 <lucasagomes> devananda, ++
17:54:04 <jroll> also, yeah, I seem to remember that doc being helpful
17:54:12 <devananda> jroll: what if services were released like clients -- when ever we want?
17:54:39 <jroll> devananda: then things would be more sane, and also infra would ragequit
17:54:41 <jroll> :P
17:54:46 <devananda> ok - so BadCub_ and I will work on updating the spreadsheet
17:54:48 <lucasagomes> heh
17:54:48 <devananda> #link https://docs.google.com/spreadsheets/d/1Hxyfy60hN_Fit0b-plsPzK6yW3ePQC5IfwuzJwltlbo
17:55:05 <devananda> jroll: actually infra doesn't care
17:55:14 <devananda> jroll: sorry - they do care. I think they would love it
17:55:14 <NobodyCam> % minutes
17:55:21 <NobodyCam> 5 even
17:55:31 <devananda> it's downstream distros that want coordinated releases
17:55:42 <jroll> devananda: twas a joke, I think the move would be difficult but after that things would be better
17:55:47 <devananda> but in a big tent, it's probably going to go away, or at least become a lot fuzzier ...
17:56:15 * jroll jumps for joy
17:56:20 <devananda> jroll: so fwiw, the TC has already laid out a framework for more projects to release the way swift does (when ever they want)
17:56:30 <lucasagomes> nice
17:56:30 <jroll> o.o link?
17:56:37 <NobodyCam> oh
17:56:40 <dtantsur> wow
17:56:56 <jroll> and going back on topic... let's get that spreadsheet updated and go from there
17:57:06 <NobodyCam> ++
17:57:07 <lucasagomes> ++
17:57:11 <dtantsur> ++
17:57:29 <naohirot> ++
17:57:47 <jroll> nice ++ train :D
17:57:48 <rloo> ++++
17:58:02 <NobodyCam> can we # agree on it
17:58:10 <wanyen> deva, can you consider raising secure boot fromlow priority to medium?  It's an ilo driver top priority item.
17:58:30 <devananda> #agree we will again be using a google doc for coordinating review priorities for the rest of this cycle
17:58:42 <NobodyCam> :)
17:58:45 <devananda> #topic open discussion
17:59:06 <dtantsur> 1 minute of OD :)
17:59:11 <NobodyCam> lol
17:59:17 * jroll thinks everybody here is doing awesome work. please discuss.
17:59:24 <dtantsur> jroll ++
17:59:32 <NobodyCam> jroll: /me seconds that thought
17:59:38 * devananda throws a puppy at jroll
17:59:40 <jroll> nothing else we're going to agree on in 60 seconds :P
17:59:41 <jroll> \o/
17:59:42 <rloo> discuss on openstack-dev email
17:59:57 * jroll cuddles said puppy
18:00:00 * BadCub_ is happy to be officially part of the gang :-)
18:00:01 <rloo> oh there was that *ED states thingy.
18:00:05 <NobodyCam> ahh a puppy
18:00:06 <dtantsur> too late
18:00:10 <devananda> rloo: nice timing
18:00:13 <lucasagomes> :D
18:00:15 <NobodyCam> lol Thank you everyone
18:00:16 <rloo> :D
18:00:18 <jlvillal> rloo: You convinced me on the *ED state thingy :)
18:00:19 <dtantsur> thanks
18:00:28 <devananda> thanks all! keep up the good work - I know it's challenging for everyone
18:00:38 <devananda> #endmeeting