14:26:15 #startmeeting openstack-chef 14:26:16 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:26:20 The meeting name has been set to 'openstack_chef' 14:26:28 Hey everyone! 14:27:28 We can start in 4 minutes officially, or there's no reason why we can't start now 14:27:49 #topic General Discussion 14:28:55 os-chef-bot: ping 14:28:55 PONG 14:30:26 Sooo I guess I'll start :) 14:30:38 #topic Ops-meetup 14:31:11 cmluciano and I visited Philly at the ops meetup 14:31:46 I was hesitant originally but glad I did do to the information I gained 14:32:17 i heard you and edgar magana crossed paths 14:32:30 markvan: you've mentioned tempest before, it never sank in with me and now it has 14:32:42 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 Hi 14:33:06 sc`: yep! Never realized you were both in the same org 14:33:15 elynn_: hi! 14:33:20 yup, tempest is a beast, but is one path to go down for testing 14:33:24 j^2: Could you help review https://review.openstack.org/#/c/162533/ and get it merge? 14:33:28 j^2: i sit 2 desks down from him at work 14:33:38 elynn_: I'll take a look asap 14:33:43 o/~ it's a small world after all o/~ 14:34:06 So before we get too off track, tempest 14:34:32 tempest rocks 14:34:44 Thaks j^2 :D 14:34:52 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 Something like the testing stack, we build it out of stackforge then roll it up when its GA 14:35:40 Any objections? 14:36:18 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 j^2: https://github.com/stackforge/cookbook-openstack-integration-test 14:36:57 Chris hodge gave us a tempest config that is a tad bit sainer teststoo 14:37:12 ours is based off of the rackspace work 14:37:16 Mattray eh? How did I miss that one? 14:37:23 :) 14:37:44 Well, that'll make life much easier 14:38:19 So with this we need to add it to the testing-stack 14:39:10 I'm betting another node to run the tests is the easy 14:39:12 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 markvan: yep that should be the next major goal 14:39:47 Agreed? 14:40:10 Then we look at Jenkins to wrap it all up 14:40:21 we have many goals...and that is a good one 14:40:31 Granted what sc` and workday have is pretty sexy too 14:40:46 i have tempest running in a container 14:41:27 +1 to testing stack on deck 14:42:26 working towards 100% test coverage with tempest, but docker's a little quirky 14:42:45 Yeah docker networking man make my head hurt 14:43:09 Ok, so tempest is the next step awesome 14:44:26 Another this I discovered is our community needs to grow. We have a realitively negative standing 14:45:00 Mark Vanderwiel proposed stackforge/cookbook-openstack-compute: Keep libvirt and device-mapper in sync on rhel https://review.openstack.org/163854 14:45:16 I think the ref Arch's and better documentation to help people see us in a more positive very will help 14:45:36 +1 14:45:45 agreed 14:45:56 I bring this up to ask if anyone has any notes or how tos to help bootstrap this on going project 14:46:29 as in community building? 14:46:38 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 If so we can take it off line and contact me directly via irc or email jj@chef.io 14:47:24 sc`: yep, we need to start looking at driving instead or kicking now ;) 14:47:47 cmluciano: all of it is community building ;) 14:47:54 absolutely 14:48:13 šŸ‘ 14:48:44 Cool, anything else on this topic? 14:49:11 Iā€™m good 14:49:40 Nice, cmluciano you wanted to talk about backlog? 14:49:48 #topic backlog 14:50:05 You have the floor :) 14:50:05 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 Just that I noticed it started piling up 14:50:47 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 Yeah its a constant battle 14:50:55 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 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 Makes sense 14:52:23 cmluciano: we probably should abandon them 14:53:42 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 I like that idea 14:54:51 Let's make the first after the hangout then 14:54:51 I would hope that would keep the back log down, and allow more dialog just on review issues 14:54:59 Agreed 14:55:17 Sometimes its just easier to talk it out 14:55:36 sure, we can give that a try 14:56:27 hi guys. 14:56:38 zhiwei: hi! 14:56:57 #topic general discussion 14:57:04 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 can we discuss this? 14:57:47 Oh wow, I haven't had a chance to read it 14:58:00 That'll be a huge change 14:58:42 not really, just some common attributes. 14:58:54 The theory is good but it could be hairy over time 14:59:26 I will upload the first patch to move the admin_tenant_name and admin_user to common cookbook. 14:59:28 then others 14:59:50 markvan: Do you have opinions on this? 14:59:56 I'm not convinced its a good idea 15:00:03 In practice 15:00:51 zhiwei: Can you possibly describe a use case for this change 15:00:56 Some guys have an requirement that they want to generate the openrc file before deploy openstack. 15:01:23 and this: https://review.openstack.org/#/c/160971/ 15:01:32 Th 15:01:38 Th 15:01:55 One sec on that ope 15:02:02 NRC thing 15:02:13 Phone acting up 15:03:10 That's a very specific use case. I don't believe that's common enough of the work 15:03:16 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 But there are chances that they might be different right? 15:04:23 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 Yrp 15:04:59 no, they would always be the same with our current approach 15:05:11 I'm just not convinced this is worth the time 15:05:39 There are multiple other things we can work on 15:05:58 I checked the code, just move the admin_tenant and admin_user to common cookbook will not spend to much time. 15:06:07 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 This seems like something that would be less priority that centos and juno suppport 15:06:41 markvan: I think they would want to declare it initailly 15:06:52 Which seems like a nice to have 15:06:56 no, the openrc file can be generated only after deploy keystone node. 15:07:17 Yeah 15:07:35 And that seems like a nice to have 15:07:49 I agree to mark this to low priority. 15:07:56 :) 15:08:15 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 ok 15:08:35 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 j^2: yeah, but we should not discourage small cleanups like this, as they also help in the long run 15:09:42 Agreed 15:10:23 ok 15:10:37 what's the plan to do next? 15:10:44 Just don't spend cycles tracking them down, but fight if you come across them 15:10:55 S/fight/fix 15:11:38 zhiwei: if you have the review already prepped let's take a look at it 15:12:13 Otherwise, I'd look for other issuses 15:12:16 On the topic of cleanup, I have another one we should be looking at 15:12:19 I am preparing the patch now, will submit it later. 15:12:52 Sounds good 15:13:00 markvan: you have the floor 15:13:16 #topic auth_token 15:13:32 This is just one of many deprecated items. 15:13:34 #topic author_ 15:13:40 Doh 15:13:46 lol 15:14:26 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 markvan: do we have a list of these collection of items? 15:14:54 j^2: hah, no, they are sometimes are to find. 15:15:18 Some have been marked deprecated since icehouse, but are still in there. 15:15:19 markvan: ah I had to ask though ;) 15:15:33 yes, we can sync the templates as well as cleanup auth_url 15:15:56 I usually just go thru the logs, and look at all the issues. Keystone is the biggest winner in this space! 15:16:06 Ha! 15:16:32 as you can see from my pipeline patch, maybe changes early in kilo: https://review.openstack.org/#/c/161859/ 15:17:31 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 Yep 15:18:22 yes, and I am also thinking to allow user inject section of key=value in templates. 15:18:59 Because we want to move our configuration from DEFAULT section to a new section of key values. 15:19:02 Having a block to do it is probably a great idea 15:19:56 yeah, I think we have a blueprint ontrying to take advantage of partial templates, which would make that very easy 15:20:22 We should probably have it in all the cookbooks for that matter 15:20:44 Does nothing by default, but there if you want it 15:21:45 yeah, I think there are some good examples of how to do that in the apache2 cookbook 15:21:47 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 zhiwei: why, that's what their for? 15:23:24 Time check: 10 mins 15:23:45 The way the oslo CONF is written, its a LIFO system, so that would be allowed in the normal cases anyway 15:23:56 not pretty, but allowed 15:24:33 ok, I just want to make users do the right thing. 15:25:14 Cool 15:25:31 Ok, 5 minutes anything else pressing? 15:26:03 j^2: I think we need more cores. 15:26:05 go team 15:26:12 Just a soapbox statement.... 15:26:21 zhiwei: agreed 15:26:44 j^2: I'd like to recomend myself as a new core, is this ok? 15:27:01 ...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 I want to contribute more on this project. 15:27:21 zhiwei as core +1 15:27:27 zhiwei: certainly, drop me a not at jj@chef.io and we can continue the discussion 15:27:45 ok, thanks. 15:28:05 i'd like to step up my contributions, too, even though they've been very little at this point 15:28:20 sc`: cool! 15:28:29 sc`: that's great news 15:29:03 sc`: thanks. 15:29:36 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 Agreed 15:29:51 šŸ‘ 15:30:14 Ok, I'm gonna call it officially done and see y'all monday 15:30:20 #endmeeting