16:00:12 <j^2> #startmeeting openstack-chef
16:00:12 <openstack> Meeting started Mon Jun 15 16:00:12 2015 UTC and is due to finish in 60 minutes.  The chair is j^2. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:15 <openstack> The meeting name has been set to 'openstack_chef'
16:00:25 <j^2> hey everyone!
16:00:28 <markvan> Howdy
16:00:37 <j^2> i’ll give a couple mins to let people join
16:00:47 <j^2> #link https://etherpad.openstack.org/p/openstack-chef-meeting-20150615
16:01:59 <sc`> hi!
16:02:06 <j^2> :D
16:03:34 <j^2> ok, cool, two mins
16:04:04 <markvan> ouch, zuul looks a bit off today...
16:04:51 <j^2> do’h, if yall don’t know about it:
16:04:53 <j^2> https://review.openstack.org/#/c/190785/
16:05:20 <j^2> #topic <sc`> c7 still requires some modifications to common to start to converge. still working on getting a converge
16:05:24 <j^2> any update here?
16:05:59 <sc`> i'm working on adding the rdo-manager repos into common based on feedback i've received
16:06:04 <j^2> nice
16:06:26 <jklare_> o/
16:06:54 <j^2> #topic  <markvan> for ubuntu, still have the outstanding libvirt issue: https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1439280
16:06:56 <openstack> Launchpad bug 1439280 in nova (Ubuntu Vivid) "Libvirt CPU affinity error" [Undecided,Confirmed]
16:07:05 <j^2> markvan: any update here?
16:07:47 <markvan> That was finally fixed in the ubuntu repo we use, yeh!
16:07:55 <j^2> sweet!
16:08:38 <j^2> so is it safe to say we can start building our testing stack reliably now?
16:08:49 <j^2> with ubuntu that is
16:09:41 <markvan> yup
16:09:47 <j^2> rock on!
16:09:59 <markvan> that's what I'm basing my CI Beta tests upon for now.
16:10:13 <j^2> #topic markvan’s ci story
16:10:19 <j^2> good segway there
16:10:57 <j^2> want to give us a quick or indepth progress report?
16:11:04 <markvan> yup, so I'm been trying to figure out if it's possible to run a very simple/basic CI that would just use the existing gate job node as a starting point.
16:11:35 <markvan> this means spinning up the openstack-chef-repo all in one type test directly within the gate job node.
16:11:54 <markvan> I have two patches out there right now that show the basic idea.
16:12:30 <j^2> awesome
16:12:33 <markvan> https://review.openstack.org/#/c/185085/  and https://review.openstack.org/#/c/188924/
16:13:36 <markvan> The repo should go in frist, and then the one for each of the cookbooks can leverage that to make it very simple ot implement.  It leave much of the control right in the repo, so future changes should be easy, just one patch.
16:14:05 <j^2> the repo one still doesn’t have the building of the neutron networks though
16:14:07 <markvan> For tests, I'm doing a few basic query and a nova boot, then running the tempest we have setup in the integration cookbook.
16:14:49 <markvan> Yup, some of the work left to do is the networking side of this.   I believe the gate job node only has 1 nic, so we need a very simple network setup.
16:15:00 <j^2> ah nice
16:15:35 <markvan> In that regard, I created a new test repo env, integration-aio-neutron.son to help develop that
16:16:17 <markvan> right now it's just a enought to allow a converge(s) to complete and a boot to work, so we can at least "kick the tires" a bit for now.
16:16:33 <jklare_> i think if we can add a basic aio nova gate which is utilized for all cookbook, that would be more than enough for the kilo release and we can do the rest in liberty
16:17:41 <markvan> yup, I agree, I'm trying to jsut get the very basic/mvp done here so at least kilo will have something.
16:17:53 <j^2> getting a aio nova build that can ping out would be great, but at the same time a aio neutron build would be crazy impressive
16:18:32 <markvan> yup, just a steady gate job will be a big step
16:18:54 <j^2> agreed
16:19:02 <markvan> So, please review my couple patches, the repo one really contains all the good stuff. and we'll go from there.
16:19:16 <j^2> :D
16:19:18 <j^2> works for me!
16:19:22 <j^2> sc`: any thoughts?
16:20:13 <jklare_> markvan sadly the check experimental jobs seem to be super slow...
16:20:48 <markvan> On a side note, one of the issues is cross cookbook patches, and how to test them in a CI gate (using Depends-On in commit msg.)   My test-patch tool in the repo does handle this already, but I think some refactoring needs to be done to make this type of this would in a zuul CI test.
16:21:07 <markvan> yup, experimental get very low priority
16:21:12 <j^2> yeah that makes sense
16:22:21 <j^2> #topic 0.6.0 ChefDK
16:23:32 <markvan> yeah, still not 0.6.x release, so I say we wait a bit on this...I see a buch of good activity on the DK.
16:23:52 <j^2> yeah it’s an extremely fast moving project
16:23:59 <j^2> it’ll have nightlies here soon
16:24:03 <markvan> I don't see an issue with leaving kilo where it is, and maybe moving this after the branch to Liberty.
16:24:53 <j^2> seems reasonable
16:25:32 <j^2> we arent gaing much by tracking master. and with a stable cut soon the idea of something that is soild and repeatble is more valubale then something shiny new
16:25:47 <jklare_> +1
16:26:12 <j^2> we want people view our stable branches and something that can be “production ready” or EXTREMELY close to drop in production ready
16:26:29 <j^2> obviously it depends on the environment and what you want, but you get the point
16:27:01 <markvan> agreed
16:27:52 <j^2> #topic kilo stable/branch cut
16:28:02 <j^2> markvan: i know you got some thoughts here :)
16:29:34 <markvan> Yeah, I think content wise we have what we need in kilo now.  so was thinking of setting a tentitive date for doing the branching, maybe in 2-3 weeks?
16:30:54 <jklare_> +1 for 2 weeks
16:31:13 <j^2> i’d prefer before i commit to anything personally, i see both ubuntu and centos sucessfully build then set the 2 weeks
16:31:20 <j^2> i still havent see it build :(
16:31:51 <jklare_> btw, do we want to keep the gate job experimental or move it in in kilo?
16:33:07 <j^2> i think we move it in kilo
16:33:46 <jklare_> in that case, i think 2 weeks are a bit too optimistic
16:34:02 <markvan> We could move it in, but leave it non-voting?   Since I think there is more work needed here to stablilze it, i'm worried that every tweak of infra will cause it to fail
16:34:41 <jklare_> i think non-voting is a good option
16:38:49 <j^2> the more i think about it non-voting seems like a great option
16:39:10 <markvan> And was wondering about using the perodic queue to maybe have the repo test run once a day?   That way we cover more of the cross cookbook issues right now.
16:40:12 <markvan> so, when we put up a patch, it would include running the repo CI gate for it's patches and once a day as well.
16:40:35 <markvan> patch/ the infra patch/
16:40:53 <j^2> can we see up a periodic test?
16:41:03 <j^2> i’m still reading the infra-manual
16:41:27 <jklare_> i think we should totally do that, since we pull in a lot of external dependencies and we only see the errors when pushing a new patch
16:41:29 <markvan> yup, I think it's pretty easy, it's just another gate, but controlled by time, rather then patches.
16:41:40 <markvan> jklare_: yup, exactly
16:42:25 <markvan> that would give us more time to work out the details on how to make the Depends-On commit hook work for us in down the road
16:43:31 <j^2> nice, i’d like to take a crack at the new gate to build daily
16:43:36 <markvan> and it would give us a heads up on when infra has tweaked something that breaks us, we'll know sooner...
16:44:08 <jklare_> sounds good
16:44:21 <jklare_> i can do the infra patches :)
16:44:38 <j^2> jklare_: :( ok, go ahead :)
16:45:11 <markvan> we could also consider just starting there for kilo and not have the individual gates on each cookbook until liberty?   (step softly at first...
16:48:19 <jklare_> so just the chef-repo patch, non-voting gate on patch and periodic?
16:48:29 <j^2> jklare_: that seems correct yeah
16:48:36 <jklare_> fits better into the timeframw of two weeks i think
16:49:45 <markvan> yes, and will then be in place already for liberty which will help from day one.
16:49:54 <j^2> agreed
16:50:20 <markvan> I think with just that in place we will learn a great deal on how to do cookbook CI...
16:50:25 <jklare_> but i am not sure if we can move the integration test in for only the chef-repo
16:50:51 <jklare_> that would probably mean either always failing and non-voting jobs for all cookbooks or another ugly regexp
16:51:20 <j^2> jklare_: not following
16:51:21 <markvan> yeah, good point. but it you just went for the periodic on the repo, that would work, right?
16:52:28 <markvan> it/if/
16:52:42 <jklare_> j^2 all the tests run for all of our repos are defined in one template, and if we move something between queues, that has an effect on all cookbooks ( the only option to avoid that is filtering with ugly regexps for specific job names)
16:52:55 <j^2> ooooh
16:53:31 <jklare_> markvan i can check how to do that and either push a patch until next monday or report why its not working ;)
16:54:04 <markvan> sounds good
16:54:19 <j^2> :D
16:55:57 <j^2> #topic Open discussion
16:56:02 <j^2> anything else?
16:56:17 <markvan> Abandon the grizzly and havana patches?
16:56:27 <j^2> yeah, i think that’s resonablp
16:57:30 <sc`> how about icehouse?
16:58:11 <sc`> some of the patches passed the gates, others did not
16:58:33 <j^2> i’m torn on icehouse
16:58:41 <j^2> our policy is n-1
16:58:56 <markvan> yeah, I guess if someone wants to work on those unit test issues, it's fine with me.
16:58:59 <j^2> granted Juno is “lts” so it’ll be around for as long 1404 is
17:01:02 * jroll is so ready for this meeting.
17:01:02 <markvan> And one last sync patch to go: https://review.openstack.org/#/c/191810/   (after that goes in, I'll respin the CI beta tests.)
17:01:18 <markvan> and this will be needed now that the library went in: https://review.openstack.org/#/c/181430/
17:01:36 * cdearborn cdearborn 1st time attending
17:01:45 <jklare_> markvan just pushed jenkins to check it again
17:01:54 <j^2> #endmeeting