15:31:26 <j^2> #startmeeting openstack-chef
15:31:27 <openstack> Meeting started Thu Dec 11 15:31:26 2014 UTC and is due to finish in 60 minutes.  The chair is j^2. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:31:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:31:31 <openstack> The meeting name has been set to 'openstack_chef'
15:31:37 <j^2> hey everyone!
15:31:46 <libsysguy> hello hello
15:31:53 <j^2> my internet access is spotty today, so if i drop i applogize ahead of time
15:31:56 <wenchma> hello everyone
15:32:41 <j^2> lets jump right in; i only have one thing i’d like to bring up, then i’ll open the floor
15:32:55 <j^2> #topic Testing-framework
15:33:11 <j^2> #link https://github.com/jjasghar/chef-openstack-testing-stack/blob/master/Rakefile
15:33:21 <j^2> I added this last night because i realized this would be extremely helpful
15:33:34 <libsysguy> omg, thank you
15:33:42 <libsysguy> I was looking for something like that
15:33:49 <markvan> hi
15:33:56 <j^2> i was wondering if i could get some eyes on it, and also if i could ask people to start adding to it, libsysguy i’m assuming you’d want ubuntu
15:34:06 <libsysguy> indeed
15:34:31 <libsysguy> I need to come up with a better way to specify the boxes
15:34:34 <libsysguy> and incorporate that into the rakefile
15:34:42 <j^2> the differeance between bundle exec and chef exec are something we’re gonna have bake in also
15:35:01 <j^2> yeah because it’s controlled by the vagrant_linux.rb that’s the long pole in the test
15:35:05 <j^2> tent
15:35:23 <libsysguy> indeed
15:35:30 <j^2> Anyway, i wanted to make sure i mentioned it
15:35:46 <libsysguy> awesome, thanks, I'll see if I can sink some more work into that
15:35:53 <j^2> also, with the help of libsysguy yesterday we’ve broken the testing-framework into two long running branches now
15:35:58 <j^2> master and stable/icehouse
15:36:11 <j^2> which is another step towards getting it on jenkins
15:36:42 <libsysguy> j^2 I was going to ask, now that you mention Jenkins, are you using squid?
15:36:53 <j^2> i’m going to on that box yeah
15:37:01 <j^2> cache the pkgs
15:37:11 <j^2> it’s dumb to pull them down every time
15:37:15 <libsysguy> I installed it but I haven't had a chance to test the time diff yet
15:37:21 <libsysguy> agreed
15:37:39 <j^2> in the lab/office i have i cut my build times of the cluster down by ~45%
15:38:06 <j^2> it used to take 70-60 mins, now it’s down to  30ish mins
15:38:23 <j^2> at home its only 23 mins, but that’s because i have i bigger pipe i’m assuming
15:39:15 <j^2> ok, cool, i’ll open the floor to any other business. if you’d like to pm me your talking point i can moderate
15:39:22 <j^2> #topic General Discussion
15:39:49 <libsysguy> follow up on my action item - it is in for review
15:41:06 <wenchma> hi, I have a topic to bring up.
15:41:06 <j^2> yay :)
15:41:11 <j^2> wenchma: go ahead
15:41:15 <wenchma> #topic bare-metal-enablement
15:41:38 <j^2> #topic bare-metal-enablement
15:41:49 <j^2> wenchma: the chair can only control bot ;)
15:42:50 <wenchma> bare metal service will be integrated in kilo release
15:43:21 <wenchma> and there is no bare metal cookbook in stackforge
15:44:04 <j^2> yep that is true, markvan you’re working on a cheatsheet for new cookbooks correct?
15:44:55 <wenchma> j^2: markvan added a wiki to detail how to create a new project
15:45:37 <j^2> it’s a skeleton at the moment, but yeah that should be the place to start looking for the information
15:46:51 <wenchma> https://wiki.openstack.org/wiki/Chef/Contributing/NewCookbook
15:48:51 <j^2> yep that’s it
15:48:55 <wenchma> j^2: I drafted the specifiction and submitted it to gerrit for review
15:48:56 <wenchma> https://review.openstack.org/#/c/140983/
15:49:06 <wenchma> any comment is welcomed
15:49:15 <j^2> awesome thanks :)
15:49:24 <j^2> #link https://review.openstack.org/#/c/140983/
15:49:46 <wenchma> yeah
15:50:34 <j^2> so i think we can all *cough*all*cough*  take an action item to look over your spec wenchma :)
15:51:01 <libsysguy> :p
15:52:30 <j^2> libsysguy: you wanted to discuss the neutron cookbook
15:53:07 <libsysguy> yup, so that cookbook is woefully out of date by juno standards
15:53:43 <j^2> #topic Neutron Cookbook
15:53:51 <libsysguy> also, it seems like there is some odd behavior due to the "common" recipe
15:53:54 <j^2> yay the bot actuall works now
15:54:10 <libsysguy> I would like to make fixing that cookbook up a blocker for the juno cut
15:54:26 <j^2> that’s a bold statement
15:54:39 * libsysguy ducks
15:55:12 <j^2> heh, so can you explain in more detail the issues you’ve found with juno and our neutron cookbook?
15:55:59 <libsysguy> sure.
15:56:15 <libsysguy> so there are two critical issues that I have noticed.  The first being that ml2 is now default and has no drivers enabled by default via the cookbooks
15:56:26 <libsysguy> we instead opt for the plugin arch of icehouse
15:57:05 <j^2> libsysguy: that’s an issue in icehouse if it’s the same thing we’re talking about
15:57:06 <j^2> https://github.com/jjasghar/chef-openstack-testing-stack/blob/master/environments/vagrant-multi-neutron.json#L44
15:58:04 <libsysguy> well that is another issue I have run across j^2, but at least that one can be worked around with overrides
15:58:10 <j^2> ah
15:58:16 <libsysguy> right now, we don't even offer template files for ml2
15:58:21 <j^2> ouch
15:59:17 <libsysguy> the upstream package maintainers ship them, but we don't touch them.  so if you look in /etc/neutron/plugins/ml2/ you only get ml2_conf.ini, when there should be several others
15:59:52 <libsysguy> one for each listed here: https://github.com/openstack/neutron/tree/master/neutron/plugins/ml2/drivers
16:00:11 <libsysguy> anyway, that is issue #1 (in no order)
16:00:20 <libsysguy> #2 is the use of common.rb
16:00:48 <libsysguy> occasionally that recipe loses sanity and installs neutron-server on all the compute nodes
16:01:17 <libsysguy> which, unless you're using the new DVR code, you really don't want
16:02:03 <j^2> is it too hair to put logic in to not do it? or it is a refactor from the ground up?
16:02:04 <libsysguy> which brings me to #3, DVR support for neutron HA is available as 'stable' in Juno
16:02:42 <libsysguy> well, as a developer, I am always for a good refactor :p
16:02:46 <j^2> heh
16:03:08 <libsysguy> I'm not sure what the best approach would be, but eventually common needs to go
16:03:20 <libsysguy> it's one giant case statement for the distros
16:03:21 <j^2> but it does what we want in juno right?
16:03:46 <j^2> i mean that _should_ be the way we do it, HA is almost *cough*always*cough* better than non-HA
16:04:14 <libsysguy> heh
16:04:16 <j^2> i like how wenchma and markvan havent chimed in at all ;)
16:04:27 <libsysguy> exactly, everyone is afraid of neutron
16:04:28 <wenchma> #action review the spec https://review.openstack.org/#/c/140983/
16:05:47 <libsysguy> I am open to suggestions on how to deal with neutron, but in it's current form, ml2 support is completely borked, there is random behavior from common.rb, and we lack DVR support
16:05:48 <wenchma> markvan is away from computer now
16:07:13 <libsysguy> I didn't mean to come to the meeting and throw a grenade but this is a major pain point for me right now setting up the juno ref arch
16:09:09 <j^2> totally, and that’s what these meetings are for
16:09:25 <j^2> so like all problems lets break it down into chunks right?
16:09:40 <libsysguy> agreed
16:09:44 <wenchma> ok
16:09:54 <wenchma> I like
16:10:01 <j^2> it sounds like the biggest bang for the buck is common, it’s stale and needs eyes on?
16:10:01 <libsysguy> the first two chunks are the blockers I see for a cut
16:10:17 <libsysguy> correct
16:10:27 <j^2> if we can just blow it away then we take out the issue, if we need to refactor then lets refactor
16:10:29 <libsysguy> common would actually address both issues I think
16:10:51 <j^2> #link https://github.com/stackforge/cookbook-openstack-network/blob/master/recipes/common.rb
16:11:01 <libsysguy> since common is handling all the mech drivers in a case statement as well
16:11:07 <j^2> jesus, this is horrible
16:11:51 <libsysguy> #link https://github.com/stackforge/cookbook-openstack-network/blob/master/recipes/common.rb#L236-L421
16:11:53 <j^2> over half of it is a case statement
16:11:54 <j^2> https://github.com/stackforge/cookbook-openstack-network/blob/master/recipes/common.rb#L236-L445
16:11:59 <libsysguy> just to handle plugins that are depricated
16:12:10 <libsysguy> yeah…
16:12:36 <j^2> so first thing first, remove the depricated options?
16:12:49 <markvan> hi again, yeah the common piece was there when those plugins where the only choice.  for ml2 this got more interesting.
16:12:50 <libsysguy> or move them into the appropriate ml2_driver
16:13:17 <j^2> hell maybe even break the plugns out to it’s own recipe at this rate
16:13:24 <libsysguy> yeah, so plugin support is still there, but they are moving to ml2 drivers
16:13:30 <markvan> humm, I don't think those others are turely deprecated just yet
16:13:57 <markvan> but our focus should be on making the main path, ml2 easier and cleaner.
16:14:05 <libsysguy> j^2 that may work long term
16:14:13 <libsysguy> markvan: I agree
16:14:48 <j^2> our happy path is ml2
16:14:52 <j^2> “happy"
16:14:57 <markvan> if that requires pushing the mono plugin logic into their own recipes, sounds good to me as a first step
16:15:08 <markvan> need to clear out the clutter before trying to make ml2 work better.
16:15:43 <markvan> and that might require it's own common-mono recipe as much of it is the same.
16:16:54 <markvan> once the clutter is gone, we can figure out what's need to move back into just the server and agent recipies and try to get rid of the current common one.
16:17:16 <j^2> seems reasonable, but we need a tactical plan to get there right?
16:18:10 <libsysguy> I would think so
16:18:17 <libsysguy> that is a huge chunk of work
16:19:12 <j^2> maybe start with an issue per, and then we can break it out per task?
16:19:12 <markvan> yup, seems like clean out common is good first step, but leave what's there for ml2 such that we don't break that path.   The real work can start on separation of ml2 from agents.
16:19:59 <markvan> would be even better to have the int test running against the basic centos ml2 path here to make sure we
16:20:25 <markvan> not breaking it along the way.   that would be getting that on juno soon.
16:21:13 <j^2> i’d offer the t-f if i could, but i still have the br-ex issue to tackle
16:21:28 <j^2> but yeah, it could totatly ferret out this very quickly
16:23:12 <libsysguy> when were we planning on cutting Juno?
16:23:18 <j^2> “january"
16:23:26 <j^2> when RC-2 is slated
16:23:47 <j^2> libsysguy: can you take some action items to create the issues, so we can start tracking portions of these changes?
16:24:01 <libsysguy> sure
16:24:45 <j^2> i think if we take our time and look through it piece by piece we should be able to knock this out
16:25:10 <libsysguy> I agree
16:25:42 <j^2> libsysguy: did we hit all the points you wated to talk about?
16:25:44 <j^2> (5 mins)
16:25:50 <libsysguy> I think so
16:26:04 <j^2> #topic General Discussion
16:26:31 <j^2> any other outstading topics?
16:26:58 <markvan> # topic new blueprints/specs
16:27:09 <j^2> #topic new blueprints/specs
16:27:23 <markvan> just a FYI,  there a couple new ones out there to review
16:27:25 <j^2> markvan: floor is yours
16:28:06 <markvan> and one is related to a adding a new cookbook for ironic, so to help with that I created a wiki page https://wiki.openstack.org/wiki/Chef/Contributing/NewCookbook to outline the basic steps for doing that work
16:28:29 <wenchma> # topic new blueprints/specs
16:28:32 <markvan> hopefully we can flush that out a bit more such that adding new cookbooks is easier.
16:28:40 <wenchma> about ironic
16:28:43 <j^2> markvan: totatly
16:28:44 <wenchma> thanks
16:29:45 <markvan> next topic i had was about juno branch and bp/bug reviews
16:30:32 <markvan> #topic juno branch
16:31:40 <markvan> Just a reminder that we need to start looking at the list of items we want in Juno branch and start pushing out the others to Kilo.  So, probably first step is to create the milestones for kilo rc and stable.
16:31:53 <j^2> yep, i can make this happen
16:32:00 <markvan> same for bugs
16:33:50 <markvan> Then we can start to focus our efforts on getting remaining juno work items done.   So, maybe early in Jan we can set tentitive dates for our juno rc, to give it some urgency
16:34:34 <j^2> kilo in launchpad has been created
16:34:36 <j^2> https://launchpad.net/openstack-chef
16:34:54 <markvan> nice, thx.
16:35:01 <wenchma> ^_^
16:35:31 <wenchma> it is I need , thx
16:37:13 <j^2> :D
16:37:15 <markvan> will be nice to have our final goals set for juno.   that's all I had.
16:37:38 <j^2> i just threw dates in for kilo we can changes those as needed
16:39:13 <j^2> i’m thinking the issues that libsysguy said should probably wrap up juno right? Do we have any other outstanding “large” issues?
16:42:13 <j^2> I’m going to end the meeting offically, but i’d like to continue discussing this in about 20-30 mins, i have to get to my office :)
16:42:15 <markvan> technically, I don't think so, but there are many to consider  (ubuntu 14, redhat 7, ruby 2.x, Rake, CI, swift, update-notify, ...)  just the tip of my list
16:42:23 <j^2> #endmeeting