15:30:00 <j^2> #startmeeting openstack-chef
15:30:01 <openstack> Meeting started Fri Sep 19 15:30:00 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:30:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:30:04 <openstack> The meeting name has been set to 'openstack_chef'
15:30:07 <j^2> Hey everyone!
15:30:10 <markvan> Howdy
15:30:29 <j^2> This week has been great for progress
15:30:40 <jklare> hi
15:30:44 <j^2> huge props to markvan for making the gates open and running again
15:30:55 <j^2> #action find a way to get markvan a beer
15:31:22 <markvan> just doing my part....
15:31:28 <j^2> I wanted to make sure we opened and congratulated with that :)
15:31:49 <brimstone> j^2: have you tested singlestack under trusty?
15:32:24 <openstackgerrit> Mark Vanderwiel proposed a change to stackforge/cookbook-openstack-compute: Add attributes for ssl_only, cert and key  https://review.openstack.org/122198
15:32:29 <j^2> i’ll start the conversation with general topics of discussion. what would yall like to talk about?
15:32:42 <j^2> #topic General Discussion
15:33:03 <markvan> I have one item that been a question for me a while now
15:33:04 <jklare> i would be interested in opinions on using chef-vault for to store secrets
15:33:12 <j^2> i’ll start the conversation with general topics of discussion. what would yall like to talk about?
15:33:42 <markvan> jklare: I have not used chef-vault much yet....what are the advantages over databags?
15:34:18 <jklare> firstly you do not have to distribute secrets anymore
15:34:46 <jklare> secondly you can encrypt secrets in a way that only the ones who need to be able to read them can read them
15:35:28 <jklare> so basically you can define secrets that can only be read by controllers
15:35:34 <j^2`> ok, so it seems i lost my irccloud account
15:35:53 <markvan> jklare: interesting...do you think it would be possible to add that in along side of what we already have for databags?
15:35:57 <j^2`> brimstone: i've been trying to
15:36:12 <j^2`> there are some issues with 14.04 and the service resource
15:36:18 <jklare> markvan: i already did that here https://review.openstack.org/122769
15:36:23 <j^2`> i actually put out a post on the chef blog yesterday about it
15:36:37 <j^2`> brimstone: the singlestack works great with centos65 though
15:36:56 <jklare> so basically it should stay an option as well as using encrypted data_bags
15:37:25 <j^2> os-chef-bot: ping
15:37:25 <os-chef-bot> PONG
15:37:26 <j^2> yay!
15:37:28 <j^2> ok i’m back
15:37:29 <markvan> jklare: k I'll take a look at that patch, but sounds like the right approach
15:38:00 <j^2> brimstone: did i answer your question?
15:38:51 <j^2> brimstone: the jist is this: https://www.getchef.com/blog/2014/09/18/chef-where-is-my-ubuntu-14-04-service-support/ in relation to Ubuntu 14.04
15:39:06 <j^2> maybe if i find some cycles today i can get it fixed
15:39:15 <j^2> i think it’s only a couple services too
15:39:19 <markvan> So are there any git rebase experts out there?   how can we avoid the Changelog collision for changes that are within the same version?   This is the last item standing in the way less rebasing.
15:39:52 <j^2> brimstone: openstack-identity, openstack-image i think just need the logic
15:40:29 <j^2> markvan: could you just squashed them and then git commit amend them?
15:41:44 <markvan> humm, is that something the git merge can do automatically for us?   that's what I want, to avoid rebasing good patches for simple Changelog collisions.
15:42:36 <j^2> hmm
15:42:50 <j^2> yeah i’m not 100% sure how gerrit/jenkins would do this for us
15:42:55 <j^2> i could do it locally….
15:43:45 <jklare> is it possible that jenkins does the rebase automatically?
15:44:05 <j^2> jklare: i havent forgotten about your vault question we’ll get to it in i bit ;)
15:45:12 <j^2> markvan: do you have an example of a review that this’ll happen if we don’t do anything?
15:45:37 <markvan> j^2: yeah, jenkins does the rebase if it can, but right now, it always fails and forces a manual rebase just for the Changelog.   Checkout https://review.openstack.org/#/c/118425/ for simple example.
15:46:13 <jklare> j^2: you saw the short discussion me and mark had on this? or did you loose these messages during your irc crash?
15:46:20 <j^2> #link https://review.openstack.org/#/c/118425/ a simple example of rebasing issue
15:46:52 <j^2> os-chef-bot: ping
15:46:52 <os-chef-bot> PONG
15:47:20 <j^2> man freenode is having troube it seems
15:47:49 <j^2> jklare: i’m reading the logs as i type this :)
15:48:31 <j^2> jklare: i tihnk my main hesitation with chef-vault is honestly I’ve never used it and i wouldnt know where to start. but the theory seems great and a perfect use case for us
15:48:37 <markvan> So, in that case, another patch was merged in dashboard, but since the Changelogs collide, I had to rebase manually.  But since in master we are allowing more activity in a single Changelog version, this should really not collide.
15:49:50 <markvan> It should not matter what order the list of changes are under a single Changelog version entry.    So, how to make rebase to smart Changelog processing for us?
15:50:30 <j^2> markvan: no idea unfortunatly
15:51:28 <markvan> yeah, I was hoping someone knows about git merge stratiegies and maybe we would write a new one for our Changelog processing....that one piece of code would save us mucho time in rebasing.
15:53:24 <markvan> #info  just for clarification later:  https://review.openstack.org/#/c/118425/1..2/CHANGELOG.md
15:53:48 <j^2> kk
15:53:51 <jklare> i think there should be a fitting option for git rebase, i will read up on that and try some things
15:54:23 <j^2> #action jklare will do some research and report back on the git rebase
15:54:36 <markvan> jklare: yeah, I'm going to ask some of our rebase experts here...maybe they have ideas on what could be done, seems like low hanging fruit to me...
15:57:49 <markvan> #topic  gates
15:57:57 <j^2> #topic gates
15:58:09 <j^2> i think you need to be a “chair” member
15:58:30 <markvan> gates are back on line.  But I did notice that our repo one is broke.  Patch forthat is here: https://review.openstack.org/#/c/121958/
15:59:12 <j^2> #chair markvan
15:59:12 <openstack> Current chairs: j^2 markvan
15:59:18 <j^2> there ya go :)(
15:59:46 <markvan> Basically we were messing with the metadata file within the gate jobs, but that it unnecessary.
16:00:11 <markvan> ok, I'll sit down then  ;)
16:00:35 <markvan> That's all I had on gate status for now.
16:01:08 <j^2> oh awesome, great catch on the metadata.rb
16:01:27 <j^2> yeah _technially_ speaking if there isn’t a metadata.rb it’s not a cookbook anymore
16:01:39 <j^2> so there’s no reason to check for it :)
16:02:50 <markvan> but the basic issue is that even tho it's not a cookbook, does not mean things like rubocop job could not be used on it
16:03:14 <j^2> ah ok
16:03:16 <markvan> (wow triple neg in that one)
16:04:06 <markvan> so trying to keep the gate jobs more pure in their intending task and nothing else.
16:04:32 <markvan> and that include the gate job pre steps.
16:05:01 <j^2> absolutely so the progression to the rakefile control will be even easier
16:06:12 <markvan> yup
16:06:22 <j^2> i’m going to try to make openstack and openstackstatus chanserv ops and no one else. i think it’s a better for the way we run
16:06:26 <j^2> fyi
16:06:57 <j^2> i have no idea who to talk to about it though
16:07:45 <j^2> did we loose brimstone?
16:08:00 <j^2> #topic General Discussion Part Deux
16:08:50 <markvan> Move to Chef 11.16?
16:09:14 <jklare> totally
16:10:51 <j^2> yep!
16:10:54 <markvan> yup, I think it's the right move for Master.  But would like to know if any other tools in our Gemfile also need to be bumped as a result of that?
16:11:12 <j^2> actaully none if we go with chefdk
16:11:29 <j^2> we can actaully rip a lot of stuff out of the gemfile with chef-dk
16:11:34 <j^2> because it’s all packaged in it
16:11:48 <markvan> yeah, but I think Chefdk is probably the next step/discussion beyond this.
16:11:57 <j^2> ah
16:13:04 <markvan> i would rather not toss the juno boat to hard with that one, but getting some tools updated (like we already did with berks 3.x) are good small steps towards that.
16:14:05 <j^2> sounds good i’m just excited to get chef-dk out there. Our little community can get a lot of help/pull/whatever you want to call it with the chef-dk guys if we adopt it sooner or latre
16:14:20 <markvan> do we need formal spec for a Chef 11.16 bump?   seems like we could make the decision here?
16:14:27 <j^2> i think we’d one of the first communities to offically adopt so we could help shape the way chef-dk works here
16:15:12 <j^2> markvan: i think it would be good practise to have the spec for it
16:15:19 <j^2> just so it becomes part of our workflow
16:15:22 <j^2> more and more
16:15:42 <markvan> #action markvan will create spec for bump to Chef 11.16
16:19:12 <j^2> awesome, any other topics?
16:19:54 <markvan> just a thanks!!! to all for helping with reviews to bring the backlog down a bit
16:20:35 <j^2> it’s like laundry, never ending war. You can win some battles but you’re always wearing something :P
16:20:51 <j^2> and i think on that note i’ll end this meeting? :)
16:23:06 <j^2> I’ll send out i mailing list with links for this and maybe get some feedback there
16:23:09 <j^2> #endmeeting