On 03/24/2017 11:22 AM, Graham Hayes wrote: > On 24/03/17 08:46 -0700, Antoni Segura Puimedon wrote: >> >> >> On Friday, March 24, 2017 at 3:59:18 PM UTC+1, Graham Hayes wrote: >> >> On 24/03/17 10:27 -0400, Davanum Srinivas wrote: >> >Folks, >> > >> >As discussed in the etherpad: >> >https://etherpad.openstack.org/p/go-and-containers >> > >> >Here's a request for a repo in OpenStack: >> >https://review.openstack.org/#/c/449641/ >> > >> >This request pulls in the existing code from kubernetes/kubernetes >> >repo and preserves the git history too >> >https://github.com/dims/k8s-cloud-provider >> > >> >Anyone interested? please ping me on Slack or IRC and we can >> continue this >> work. >> >> Yeah - I would love to continue the provider work on gerrit :) >> >> Is there a way for us to make sure changes in the k8 master don't >> break our plugin? Or do we need to periodic jobs on the provider repo >> to catch breakages in the plugin interface? >> >> >> I suppose the options are either: >> >> ask k8s to add select external cloud providers in the CI >> Have a webhook in the k8s repo that triggered CI on the OSt infra >> > > Yup - I just want to have us get our ducks in a row before we make a > move. > > From our side, we should look at the support matrix of what OpenStack > versions we support, and how we plan on testing them in -infra.
We will have better first-class support for this in a few months as part of rolling out zuul v3. Once the github branch lands and we get v3 rolled out for non-infra projects, we'll be able to cross-test things in gerrit with things not in gerrit (we have a similar need to be able to test that ansible PRs don't break zuul) For now, if you can make sure that you have a test that can install the k8s repo from source, and also that is structured such that if it discovers that the k8s repo is there that it will not re-clone, we should be able to upgrade that in the future to having zuul manage the triggering and cloning. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
