17:00:19 <asselin> #startmeeting third-party
17:00:22 <openstack> Meeting started Tue Mar  8 17:00:19 2016 UTC and is due to finish in 60 minutes.  The chair is asselin. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:26 <openstack> The meeting name has been set to 'third_party'
17:01:03 <asselin> anyone here for 3rd party working meeting?
17:01:51 <mmedvede> hi asselin
17:02:08 * mmedvede was fighting fires
17:02:24 <asselin> hi mmedvede
17:02:31 <asselin> fires under control?
17:02:41 <mmedvede> yes
17:03:21 <asselin> #topic announcements
17:03:29 <asselin> any announcements?
17:03:55 <asselin> #topic CI Watch
17:04:30 <mmedvede> no news since last meeting
17:04:47 <mmedvede> #link ciwatch unittests review queue https://review.openstack.org/#/q/status:open+project:openstack-infra/ciwatch+branch:feature/unit-tests+topic:ci-dashboard
17:05:32 <asselin> Anything specific? or just review all of them?
17:05:40 <mmedvede> I was not merging any of it yet, asselin feel free +2 if you think it works well
17:05:48 <asselin> will do
17:06:11 <mmedvede> asselin: so I realized that we can not merge from master or back to master yet
17:06:40 <asselin> oh? what does that mean exactly
17:06:50 <mmedvede> there are fixes on master that I'd like to get backported
17:07:04 <mmedvede> asselin: you can not push merge commits, need special permissions
17:07:19 * mmedvede looks for patch
17:07:20 <asselin> I thought we enabled that
17:07:50 <mmedvede> #link https://review.openstack.org/#q,Ie645ef86551de74e3f53b8405e0d00f73f9c9b41,n,z
17:08:40 <mmedvede> asselin: no, we did not. And you also need to be a member of ciwatch-release group, which now only has infra in it
17:08:56 <asselin> yeah seein ghtat
17:10:04 <asselin> ok I can ask about adding us to that
17:10:15 <asselin> anything else?
17:11:06 <mmedvede> no, I think we can finally add some real unit tests next
17:11:39 <asselin> ok cool!
17:11:57 <asselin> #topic Common-CI Solution
17:13:06 <asselin> only new issue is that the current docs basically ask users to reuse openstack-infra/system-config
17:13:34 <asselin> and this points to some pip sites that aren't recommended or accessible outside of -infra.
17:13:36 <mmedvede> for install_modules.sh and image building, correct?
17:13:42 <asselin> yes
17:14:06 <asselin> and install_puppet.sh
17:14:18 <asselin> but that one is less of a concern than the ones you mention
17:14:45 <mmedvede> I see no problems with reusing install_puppet and modules
17:14:47 <asselin> so there's a need to perhaps make image building more easily reusable by 3rd party folks
17:14:53 <mmedvede> image building is confusing matters though
17:15:54 <mmedvede> there is dib image builds, and there is image update that e.g. uses prepare_node.sh
17:16:56 <mmedvede> asselin: we could just say that image building is up to third-party CI maintainers, and see system-config for example
17:17:34 <asselin> yeah....that's bascially what it says now....but folks are having trouble with 'how to debug and maintain' image builds.
17:17:35 <mmedvede> another way is to create a separate spec for pulling image building out
17:17:46 <mmedvede> (I think it is a big effort)
17:18:53 <asselin> yeah. Not sure who'd do the work though....maybe if we write the spec we'll find some volunteers to drive the effort?
17:20:58 <mmedvede> It is tricky to estimate what it would take. I am familiar with prepare_node way. Less so with dib
17:21:14 <asselin> it's basically the same thing
17:21:52 <mmedvede> yes, both simply running bunch of scripts to get images ready
17:22:12 <mmedvede> one of them involves puppet though
17:22:23 <asselin> they both do, actually
17:22:39 <mmedvede> they do? I thought dib just used elements
17:22:47 <asselin> yes, and the element calls puppet :)
17:22:54 <mmedvede> do some of those elements apply some puppet manifests from system-config?
17:23:19 <asselin> elements are just script snippets. DIB composes them wherease snapshot-images you have to compose them
17:23:28 <asselin> yes
17:24:33 <asselin> #link https://git.openstack.org/cgit/openstack-infra/project-config/tree/nodepool/elements/puppet/bin/prepare-node
17:24:42 <mmedvede> you see, for me it is hard to imagine how to abstract image building puppet manifests from system-config. Our images have a lot of custom setup in them
17:25:40 <asselin> bascially class {'openstack_project::single_use_slave': needs to be openstackci::signle_use_slave
17:26:09 <mmedvede> asselin: yes, but it might pull in a whole lot of things with it
17:26:33 <asselin> yes, probably need to strip it down a bit
17:26:39 <mmedvede> it is also very specific for building only particular type of images
17:26:58 <asselin> these are for the devstack images which (I think) is the common case for 3rd party ci
17:27:33 <mmedvede> I mean, some people might use different OS, or arch (points finger at self)
17:28:10 <asselin> actually maybe only this is needed: https://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/single_use_slave.pp#n43
17:30:15 <asselin> #link but slave_common.pp also looks important: https://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/slave_common.pp
17:30:30 <asselin> anyway perhaps these can be done in project-config-example
17:30:54 <asselin> instead of asking users to copy from project-config
17:32:13 <asselin> but we should write a spec to detail the work and get more feedback
17:32:39 <asselin> #action asselin write a spec to create image builds reusable by 3rd party ci
17:33:48 <asselin> #topic Open Discussion
17:33:53 <mmedvede> asselin: maybe start with etherpad instead first, just to iterate initial work estimate quicker?
17:34:06 <asselin> mmedvede, sure, good idea
17:34:54 <asselin> anything else to discuss?
17:35:32 <mmedvede> I have already discussed apparent zuul memory leak during Mon meeting
17:35:43 <mmedvede> (there is also email thread)
17:36:34 <mmedvede> So if anyone else experiences higher memory footprint of zuul-server, please speak up
17:37:13 <asselin> I haven't noticed it on our end. I'll have to check which version we're using
17:37:41 <mmedvede> it is slow (if it is a leak), about 500Mb a day
17:37:59 <mmedvede> so on my VM with 8GB could take a whole week or longer
17:38:07 <mmedvede> before crashing
17:38:49 <asselin> we're on this version: https://review.openstack.org/#/c/262579/
17:38:52 <mmedvede> #link zuul memory leak thread http://lists.openstack.org/pipermail/openstack-infra/2016-March/003971.html
17:39:15 <mmedvede> asselin: what version shows up on the bottom of zuul ui?
17:39:40 <asselin> Zuul version:
17:39:48 <asselin> Zuul version: 2.1.1.dev121
17:41:01 <mmedvede> looks like the one before the patch that should fix the leak. So if anything, you should see more problems
17:41:23 <mmedvede> asselin: do you know if your zuul gets restarted regurarly?
17:41:43 <asselin> we did restart it 'regularly' but due to other issues
17:42:05 <asselin> which patch fixes the leak?
17:42:29 <mmedvede> asselin: allegedly fixes the leak
17:42:44 <asselin> sorry....alegedly :)
17:42:53 <mmedvede> #link https://review.openstack.org/#q,I81ee47524cda71a500c55a95a2280f491b1b63d9,n,z
17:43:08 <mmedvede> asselin: ^
17:43:48 <asselin> ok thanks
17:45:23 <asselin> anyone else around have something to discuss?
17:45:34 <mmedvede> I think zuul.o.o just recently got updated to the most recent version, so would be interesting to see if they have the same problem
17:46:55 <asselin> yeah. I'm going to pay more attention to ours.
17:48:34 <asselin> mmedvede, anything else to discuss?
17:48:40 <mmedvede> no
17:48:56 <asselin> ok thanks for the good discussion
17:49:03 <asselin> #endmeeting