17:00:05 <asselin> #startmeeting third-party
17:00:06 <openstack> Meeting started Tue Jul  7 17:00:05 2015 UTC and is due to finish in 60 minutes.  The chair is asselin. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:10 <openstack> The meeting name has been set to 'third_party'
17:00:31 <asselin> hi, who's here for 3rd party ci working group meeting?
17:00:54 <mmedvede> o/
17:01:09 <asselin> hi mmedvede
17:02:14 <patrickeast> hey
17:02:46 <asselin> hi patrickeast
17:04:02 <asselin> #link agenda https://wiki.openstack.org/wiki/Meetings/ThirdParty#7.2F7.2F15_1700_UTC
17:04:16 <asselin> we have two topics
17:04:56 <asselin> #topic Common CI virtual sprint preparation
17:05:28 <asselin> #info virtual sprint is tomorrow
17:05:37 <asselin> we got common-zuul done last week.
17:05:57 <asselin> have either of you switched to using it?
17:06:28 <mmedvede> I did
17:06:44 <patrickeast> not yet
17:06:46 <mmedvede> Although I still have to use a couple of patches on top of it
17:06:51 <asselin> mmedvede, cool
17:07:04 <asselin> mmedvede, can you elaborate?
17:08:00 <mmedvede> asselin: sure. We need to have ability to specify project config revision
17:08:19 <mmedvede> asselin: this is the patch I need:
17:08:22 <mmedvede> #link https://review.openstack.org/#/c/198546/
17:08:55 <asselin> mmedvede, cool yeah will take a look today
17:09:12 <asselin> mmedvede, we should have something like that for each of the components
17:09:19 <mmedvede> asselin: it also seems that project revision passthrough should be added to the rest of downstream puppet modules
17:09:25 <mmedvede> +1
17:09:27 <asselin> mmedvede, +1
17:10:04 <mmedvede> In a similar note, zuul_scheduler does not have revision parameter for zuul repo
17:10:20 <mmedvede> I might submit the patches during sprint
17:10:37 <asselin> mmedvede, yes
17:11:18 <asselin> mmedvede, I do want to focus on the remaining components for the sprint.
17:11:39 <asselin> mmedvede, currently that's nodepool and JJB
17:12:04 <mmedvede> asselin: question - are we going to keep "thinning out" system config more after sprint? E.g. we still have to maintain some copies of system-config code.
17:12:34 <asselin> mmedvede, which parts of system config do you still need?
17:13:09 <asselin> mmedvede, the goal of the sprint is so that 3rd party ci can be setup w/ as little of system-config as possible....
17:13:56 <asselin> mmedvede, also the scope of the sprint is to focus on the spec:http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html
17:14:23 <mmedvede> One example is system-config/modules/openstack_project/manifest/jenkins.pp still has jjb. But I guess that what you meant above by concentrating on JJB
17:14:24 <asselin> things like gerrit, etc. would be done in a new spec/phase 3
17:15:00 <asselin> *phase 2
17:15:40 <asselin> #link this patch should be used for JJB https://review.openstack.org/#/c/184919/
17:16:51 <mmedvede> asselin: ok, makes sense. The current spec does not have all the tasks that need to happen, and more refactoring of system-config would be done.
17:17:10 <asselin> mmedvede, what task needs to be added?
17:17:31 <asselin> #link common-ci tasks: https://storyboard.openstack.org/#!/story/2000101
17:17:35 <mmedvede> sorry for having so many questions. I feel that if I reviewed more patches I would be more in-the-loop
17:17:48 <asselin> mmedvede, no problem, ask away
17:18:57 <asselin> mmedvede, would like to identify missing pieces sooner than later
17:18:59 <mmedvede> asselin: the "masterless puppet" task - can you elaborate what it involves?
17:19:57 <asselin> mmedvede, the idea is to be able to setup a 3rd party ci system on a single node. This would be the starting point for new 3rd party folks...the glue that ties everything together
17:21:12 <mmedvede> asselin: this might answer my next question
17:21:37 <mmedvede> I did not know what we were supposed to use in place of system-config to glues things together
17:22:04 <asselin> mmedvede, so basically a verion of this that can be customized by each vendor: https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/manifests/master.pp or https://github.com/openstack-infra/system-config/blob/master/manifests/site.pp
17:23:36 <asselin> I proposed masterless as I think that is simpler to setup
17:23:53 <asselin> mmedvede, do you agree?
17:25:06 <mmedvede> asselin: I agree that masterless is easier to setup. But I am not sure how that would translate into ease of use, as long as upstream modules still utilize master and hiera. But I honestly did not look into it.
17:25:45 <mmedvede> asselin: For example, I am utilizing hiera encryption on master, so I can store my hiera in the same repo as everything else
17:27:14 <asselin> mmedvede, yes, I think that would be a good direction: masterless puppet, with the ability to set module versions (pin for stabilty) and use encrypted heira
17:28:57 <asselin> mmedvede, do you think that would work? good compromise for ease of installation, use, and maintanability?
17:30:18 <mmedvede> asselin: I need to understand how hiera works without master. When you have master, you have single point where you need to maintain encryption keys.
17:32:00 <asselin> mmedvede, when you use a puppet master, how are the encryption keys stored?
17:32:17 <mmedvede> asselin: it is hard to know if it would work without seeing it work :) So I definitely support the direction
17:32:48 <mmedvede> asselin: puppet-master creates private key to use specifically for hiera encryption
17:33:15 <mmedvede> asselin: this key is only kept on master, and optionally backed up by hand
17:33:18 <asselin> mmedvede, ok, I see
17:33:50 <mmedvede> asselin: so then you can use public key to encrypt hiera, and only master would be able to use it
17:35:36 <asselin> mmedvede, so more investigation is needed
17:36:48 <asselin> mmedvede, let's see how far we can get in the sprint. If we can get basics wokring, I would consider that a success. We can always improve from there.
17:37:24 <mmedvede> asselin: I think simplicity wins over having master. +1
17:38:11 <asselin> mmedvede, sounds like you're willing to help out with that part during the sprint?
17:39:08 <mmedvede> I am willing :) I took logstash task though
17:39:26 <asselin> mmedvede, oh really, great! didn't see that
17:39:56 <mmedvede> logstash it is low priority. So let me know if you think I can help somewhere else
17:40:20 <asselin> mmedvede, it's not essential, but certainly very valuable
17:40:40 <mmedvede> great then :)
17:40:56 <rfolco> same here asselin, willing to help but don know where to start
17:41:00 <asselin> mmedvede, I'll let you pick, you can do both :).
17:41:10 <asselin> hi rfolco
17:41:58 <asselin> rfolco, you can help out where your interests are. you work with mmedvede right?
17:42:23 <rfolco> asselin, yes, correct. Tasks look big, maybe we can break into smaller sub-tasks ?
17:42:39 <asselin> ok I see...you each took on half of the logstash/kibana
17:42:59 <asselin> rfolco, storyboard isn't that great for sub-tasks
17:43:12 <asselin> rfolco, so I kept them high-level
17:43:17 <rfolco> I see
17:43:39 <mmedvede> We can probably split them as we go if needed, in the etherpad
17:43:51 <asselin> mmedvede, yeah
17:43:56 <mmedvede> #link https://etherpad.openstack.org/p/common-ci-sprint
17:45:30 <asselin> ok, anything else? otherwise we should change to topic #2
17:45:42 <mmedvede> nope, thanks asselin
17:46:28 <asselin> rfolco, mmedvede I think it's fine you work together on logstash. I'll pick up the masterless puppet task if noone else wants it :)
17:47:10 <rfolco> sounds good to me
17:47:14 <asselin> #topic Spec to have infra host scoreboard (krtaylor)
17:47:58 <asselin> I think krtaylor is out this week. anyone have any updates to issues to discuss?
17:48:19 <asselin> #link scoreboard spec https://review.openstack.org/#/c/194437/
17:48:31 <asselin> patrickeast, you still around?
17:48:37 <mmedvede> There is some questions about new spec relation to the old dashboard
17:48:46 <patrickeast> asselin: yea mostly
17:48:54 * patrickeast catching up on scrollback
17:49:29 <patrickeast> ah yea, so i’m not sure what we need to do to get that spec moving
17:49:48 <patrickeast> jogo has proposed a pretty cool alternative too
17:49:55 <asselin> link?
17:50:07 <patrickeast> its in the review
17:50:10 <patrickeast> sec
17:50:16 <patrickeast> http://jogo.github.io/lastcomment/
17:50:24 <mmedvede> the lastcomment serves different purpose though
17:50:28 <asselin> #link http://jogo.github.io/lastcomment/
17:50:29 <patrickeast> yea
17:50:38 <patrickeast> maybe more complimentary to the scoreboard
17:50:50 <mmedvede> +1 on complimentary, not alternative
17:52:22 <asselin> to move forward, we can add to the infra meeting agenda
17:52:37 <mmedvede> Intention of the spec needs to be made clearer, so there is not confusion that it tries to replace the dashboard spec
17:52:38 <asselin> not sure if today is too late
17:52:58 <asselin> we can add it, and perhaps get votes by next week
17:57:05 <asselin> so it is ready to add to agenda? or should we iterate one more time?
17:57:29 <mmedvede> asselin: the comments need to be addressed first
17:58:17 <asselin> jhesketh's comments? he -1 and rollcall +1...not sure what that means
17:58:43 <mmedvede> yes, I was referring to jhesketh comments
17:59:37 <asselin> #topic open discussion
17:59:54 <mmedvede> asselin: thank you for leading the meeting today!
18:00:09 <asselin> thanks...see you all tomorrow!
18:00:15 <asselin> #end-meeting
18:00:17 <patrickeast> cya
18:00:21 <asselin> #endmeeting