14:26:15 <j^2> #startmeeting openstack-chef
14:26:16 <openstack> Meeting started Thu Mar 12 14:26:15 2015 UTC and is due to finish in 60 minutes.  The chair is j^2. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:26:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:26:20 <openstack> The meeting name has been set to 'openstack_chef'
14:26:28 <j^2> Hey everyone!
14:27:28 <j^2> We can start in 4 minutes officially, or there's no reason why we can't start now
14:27:49 <j^2> #topic General Discussion
14:28:55 <j^2> os-chef-bot: ping
14:28:55 <os-chef-bot> PONG
14:30:26 <j^2> Sooo I guess I'll start :)
14:30:38 <j^2> #topic Ops-meetup
14:31:11 <j^2> cmluciano and I visited Philly at the ops meetup
14:31:46 <j^2> I was hesitant originally but glad I did do to the information I gained
14:32:17 <sc`> i heard you and edgar magana crossed paths
14:32:30 <j^2> markvan: you've mentioned tempest before, it never sank in with me and now it has
14:32:42 <cmluciano> Iā€™m trying to write up a blog post about it, you can take a look at all of the etherpad note links here http://lists.openstack.org/pipermail/openstack-operators/2015-February/006268.html
14:32:55 <elynn_> Hi
14:33:06 <j^2> sc`: yep! Never realized you were both in the same org
14:33:15 <j^2> elynn_: hi!
14:33:20 <markvan> yup, tempest is a beast, but is one path to go down for testing
14:33:24 <elynn_> j^2: Could you help review https://review.openstack.org/#/c/162533/ and get it merge?
14:33:28 <sc`> j^2: i sit 2 desks down from him at work
14:33:38 <j^2> elynn_: I'll take a look asap
14:33:43 <sc`> o/~ it's a small world after all o/~
14:34:06 <j^2> So before we get too off track, tempest
14:34:32 <sc`> tempest rocks
14:34:44 <elynn_> Thaks j^2 :D
14:34:52 <j^2> We don't have a cookbook for it. Unless someone wants to own it, I believe it needs to become my next highest priority
14:35:32 <j^2> Something like the testing stack, we build it out of stackforge then roll it up when its GA
14:35:40 <j^2> Any objections?
14:36:18 <sc`> j^2: might it be useful to drum up a conversation with the author of our tempest cookbook? just from first glance, it looks close to being viable for public consumption
14:36:19 <mattray> j^2: https://github.com/stackforge/cookbook-openstack-integration-test
14:36:57 <j^2> Chris hodge gave us a tempest config that is a tad bit sainer teststoo
14:37:12 <sc`> ours is based off of the rackspace work
14:37:16 <j^2> Mattray eh? How did I miss that one?
14:37:23 <mattray> :)
14:37:44 <j^2> Well, that'll make life much easier
14:38:19 <j^2> So with this we need to add it to the testing-stack
14:39:10 <j^2> I'm betting another node to run the tests is the easy
14:39:12 <markvan> yup, that was the plan all along.  Probably first we need to "fine tune" the testing stack repo to actually get setup correctly to allow a integration test to run.
14:39:39 <j^2> markvan: yep that should be the next major goal
14:39:47 <j^2> Agreed?
14:40:10 <j^2> Then we look at Jenkins to wrap it all up
14:40:21 <markvan> we have many goals...and that is a good one
14:40:31 <j^2> Granted what sc` and workday have is pretty sexy too
14:40:46 <sc`> i have tempest running in a container
14:41:27 <cmluciano> +1 to testing stack on deck
14:42:26 <sc`> working towards 100% test coverage with tempest, but docker's a little quirky
14:42:45 <j^2> Yeah docker networking man make my head hurt
14:43:09 <j^2> Ok, so tempest is the next step awesome
14:44:26 <j^2> Another this I discovered is our community needs to grow. We have a realitively negative standing
14:45:00 <openstackgerrit> Mark Vanderwiel proposed stackforge/cookbook-openstack-compute: Keep libvirt and device-mapper in sync on rhel  https://review.openstack.org/163854
14:45:16 <j^2> I think the ref Arch's and better documentation to help people see us in a more positive very will help
14:45:36 <sc`> +1
14:45:45 <markvan> agreed
14:45:56 <j^2> I bring this up to ask if anyone has any notes or how tos to help bootstrap this on going project
14:46:29 <cmluciano> as in community building?
14:46:38 <sc`> testing stack makes it easier to kick the tires, too, without having to rely on having chef infrastructure of some sort in place
14:46:49 <j^2> If so we can take it off line and contact me directly via irc or email jj@chef.io
14:47:24 <j^2> sc`: yep, we need to start looking at driving instead or kicking now ;)
14:47:47 <j^2> cmluciano: all of it is community building ;)
14:47:54 <sc`> absolutely
14:48:13 <cmluciano> šŸ‘
14:48:44 <j^2> Cool, anything else on this topic?
14:49:11 <cmluciano> Iā€™m good
14:49:40 <j^2> Nice, cmluciano you wanted to talk about backlog?
14:49:48 <j^2> #topic backlog
14:50:05 <j^2> You have the floor :)
14:50:05 <openstackgerrit> Ma Wen Cheng proposed stackforge/openstack-chef-repo: Include the recipe identity_registration in os-bare-metal-api role  https://review.openstack.org/163721
14:50:11 <cmluciano> Just that I noticed it started piling up
14:50:47 <cmluciano> Partly since you and I probably have not had the time to review newer things but I also noticed that we have 4-6 changes dating back from Dec
14:50:49 <j^2> Yeah its a constant battle
14:50:55 <markvan> yup, I've been busy finding small bugs and trying to get them posted so we can get the out of the way early in the dev cycle
14:51:48 <cmluciano> I see at least 3 from Elliot that probably need owners or abandoned since he mentioned that he doesnt have the cycles anymore
14:51:50 <j^2> Makes sense
14:52:23 <j^2> cmluciano: we probably should abandon them
14:53:42 <markvan> I was think about having some sort of code review office hours, maybe the hour following our 2 meetings, just to focus twice a week on reviews
14:53:55 <cmluciano> I like that idea
14:54:51 <j^2> Let's make the first after the hangout then
14:54:51 <markvan> I would hope that would keep the back log down, and allow more dialog just on review issues
14:54:59 <j^2> Agreed
14:55:17 <j^2> Sometimes its just easier to talk it out
14:55:36 <markvan> sure, we can give that a try
14:56:27 <zhiwei> hi guys.
14:56:38 <j^2> zhiwei: hi!
14:56:57 <j^2> #topic general discussion
14:57:04 <zhiwei> I created a blueprint to move the common attributes to common cookbooks: https://blueprints.launchpad.net/openstack-chef/+spec/move-attributes-to-common
14:57:08 <zhiwei> can we discuss this?
14:57:47 <j^2> Oh wow, I haven't had a chance to read it
14:58:00 <j^2> That'll be a huge change
14:58:42 <zhiwei> not really, just some common attributes.
14:58:54 <j^2> The theory is good but it could be hairy over time
14:59:26 <zhiwei> I will upload the first patch to move the admin_tenant_name and admin_user to common cookbook.
14:59:28 <zhiwei> then others
14:59:50 <cmluciano> markvan: Do you have opinions on this?
14:59:56 <j^2> I'm not convinced its a good idea
15:00:03 <j^2> In practice
15:00:51 <cmluciano> zhiwei: Can you possibly describe a use case for this change
15:00:56 <zhiwei> Some guys have an requirement that they want to generate the openrc file before deploy openstack.
15:01:23 <zhiwei> and this: https://review.openstack.org/#/c/160971/
15:01:32 <j^2> Th
15:01:38 <j^2> Th
15:01:55 <j^2> One sec on that ope
15:02:02 <j^2> NRC thing
15:02:13 <j^2> Phone acting up
15:03:10 <j^2> That's a very specific use case. I don't believe that's common enough of the work
15:03:16 <markvan> It's fairly reasonable to expect that we should be looking for DRY type of changes, and this is a good one to consider, basically not having each cookbook figure out how to go after the basic admin creds that are really already owned by Common.
15:04:19 <j^2> But there are chances that they might be different right?
15:04:23 <markvan> And this would be a segway into why and how the cookbooks are using/abusing those creds right now, but that's a different discussion.
15:04:31 <j^2> Yrp
15:04:59 <markvan> no, they would always be the same with our current approach
15:05:11 <j^2> I'm just not convinced this is worth the time
15:05:39 <j^2> There are multiple other things we can work on
15:05:58 <zhiwei> I checked the code, just move the admin_tenant and admin_user to common cookbook will not spend to much time.
15:06:07 <markvan> zhiwei: we already have a openrc recipe in common, which I think could be used to generate that file whenever it's needed, right?
15:06:19 <j^2> This seems like something that would be less priority that centos and juno suppport
15:06:41 <j^2> markvan: I think they would want to declare it initailly
15:06:52 <j^2> Which seems like a nice to have
15:06:56 <zhiwei> no, the openrc file can be generated only after deploy keystone node.
15:07:17 <j^2> Yeah
15:07:35 <j^2> And that seems like a nice to have
15:07:49 <zhiwei> I agree to mark this to low priority.
15:07:56 <j^2> :)
15:08:15 <markvan> Having a common admin_tenant and user seems like a good idea, if your willing, go for it and we'll see how the reviews look.
15:08:27 <zhiwei> ok
15:08:35 <j^2> Its something that could be useful and good in the long run, but we have many other things we should be looking at
15:09:33 <markvan> j^2: yeah, but we should not discourage small cleanups like this, as they also help in the long run
15:09:42 <j^2> Agreed
15:10:23 <zhiwei> ok
15:10:37 <zhiwei> what's the plan to do next?
15:10:44 <j^2> Just don't spend cycles tracking them down, but fight if you come across them
15:10:55 <j^2> S/fight/fix
15:11:38 <j^2> zhiwei: if you have the review already prepped let's take a look at it
15:12:13 <j^2> Otherwise, I'd look for other issuses
15:12:16 <markvan> On the topic of cleanup, I have another one we should be looking at
15:12:19 <zhiwei> I am preparing the patch now, will submit it later.
15:12:52 <j^2> Sounds good
15:13:00 <j^2> markvan: you have the floor
15:13:16 <markvan> #topic auth_token
15:13:32 <markvan> This is just one of many deprecated items.
15:13:34 <j^2> #topic author_
15:13:40 <j^2> Doh
15:13:46 <cmluciano> lol
15:14:26 <markvan> For this one, we need to use just the auth url instead of the separate pieces.   Should be very straight forward, but needs to probably get done in kilo and itwill be pulled in liberty
15:14:30 <j^2> markvan: do we have a list of these collection of items?
15:14:54 <markvan> j^2: hah, no, they are sometimes are to find.
15:15:18 <markvan> Some have been marked deprecated since icehouse, but are still in there.
15:15:19 <j^2> markvan: ah I had to ask though ;)
15:15:33 <zhiwei> yes, we can sync the templates as well as cleanup auth_url
15:15:56 <markvan> I usually just go thru the logs, and look at all the issues.   Keystone is the biggest winner in this space!
15:16:06 <j^2> Ha!
15:16:32 <markvan> as you can see from my pipeline patch, maybe changes early in kilo: https://review.openstack.org/#/c/161859/
15:17:31 <markvan> zhiwei: yup, our CONF templates are always in need of updates for deprecated items, especially since the base has been moving hard to put all key in sections.
15:18:18 <j^2> Yep
15:18:22 <zhiwei> yes, and I am also thinking to allow user inject section of key=value in templates.
15:18:59 <zhiwei> Because we want to move our configuration from DEFAULT section to a new section of key values.
15:19:02 <j^2> Having a block to do it is probably a great idea
15:19:56 <markvan> yeah, I think we have a blueprint ontrying to take advantage of partial templates,  which would make that very easy
15:20:22 <j^2> We should probably have it in all the cookbooks for that matter
15:20:44 <j^2> Does nothing by default, but there if you want it
15:21:45 <markvan> yeah, I think there are some good examples of how to do that in the apache2 cookbook
15:21:47 <zhiwei> I think this is a tough thing, do we need to guard users don't add the exist sections to the partial templates?
15:22:15 <markvan> zhiwei: why, that's what their for?
15:23:24 <j^2> Time check: 10 mins
15:23:45 <markvan> The way the oslo CONF is written, its a LIFO system, so that would be allowed in the normal cases anyway
15:23:56 <markvan> not pretty, but allowed
15:24:33 <zhiwei> ok, I just want to make users do the right thing.
15:25:14 <j^2> Cool
15:25:31 <j^2> Ok, 5 minutes anything else pressing?
15:26:03 <zhiwei> j^2: I think we need more cores.
15:26:05 <cmluciano> go team
15:26:12 <markvan> Just a soapbox statement....
15:26:21 <j^2> zhiwei: agreed
15:26:44 <zhiwei> j^2: I'd like to recomend myself as a new core, is this ok?
15:27:01 <markvan> ...that more folks start running at least the testing stack aio_nova case with their patches, we're finding some issues that should have been caught by doingthat
15:27:08 <zhiwei> I want to contribute more on this project.
15:27:21 <markvan> zhiwei  as core +1
15:27:27 <j^2> zhiwei: certainly, drop me a not at jj@chef.io and we can continue the discussion
15:27:45 <zhiwei> ok, thanks.
15:28:05 <sc`> i'd like to step up my contributions, too, even though they've been very little at this point
15:28:20 <markvan> sc`: cool!
15:28:29 <j^2> sc`: that's great news
15:29:03 <zhiwei> sc`: thanks.
15:29:36 <markvan> j^2: one last item, we talked about some priorities here, we should continue that discussion on Monday by goingthru the existing blueprints/specs and getting a baseline to help communicate what we're working on
15:29:45 <j^2> Agreed
15:29:51 <cmluciano> šŸ‘
15:30:14 <j^2> Ok, I'm gonna call it officially done and see y'all monday
15:30:20 <j^2> #endmeeting