Excerpts from Chris Hoge's message of 2017-04-04 17:09:11 -0400: > > > On Apr 2, 2017, at 4:29 PM, Monty Taylor <mord...@inaugust.com> wrote: > > > > On 03/29/2017 03:39 PM, Steve Gordon wrote: > >> ----- Original Message ----- > >>> From: "Davanum Srinivas" <dava...@gmail.com> > >>> To: "Chris Hoge" <ch...@openstack.org> > >>> Cc: "OpenStack Development Mailing List (not for usage questions)" > >>> <openstack-dev@lists.openstack.org>, > >>> "kubernetes-sig-openstack" <kubernetes-sig-openst...@googlegroups.com> > >>> Sent: Wednesday, March 29, 2017 2:28:29 PM > >>> Subject: Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud > >>> Provider for Kubernetes > >>> > >>> Team, > >>> > >>> Repo is ready: > >>> http://git.openstack.org/cgit/openstack/k8s-cloud-provider > >>> > >>> I've taken the liberty of updating it with the latest changes in the > >>> kubernetes/kubernetes repo: > >>> https://review.openstack.org/#/q/project:openstack/k8s-cloud-provider is > >>> ready > >>> > >>> So logical next step would be to add CI jobs to test in OpenStack > >>> Infra. Anyone interested? > >> > >> One question I have around this - do we have a shared view of what the > >> ideal matrix of tested combinations would like? E.g. kubernetes master on > >> openstack project's master, kubernetes master on openstack project's > >> stable branches (where available), do we also need/want to test kubernetes > >> stable milestones, etc. > >> > >> At a high level my goal would be the same as Chris's "k8s gating on > >> OpenStack in the same ways that it does on AWS and GCE." which would imply > >> reporting results on PRs proposed to K8S master *before* they merge but > >> not sure we all agree on what that actually means testing against in > >> practice on the OpenStack side of the equation? > > > > I think we want to have jobs that have the ability to test: > > > > 1) A proposed change to k8s-openstack-provider against current master of > > OpenStack > > 2) A proposed change to k8s-openstack-provider against a stable release > > of OpenStack > > 3) A proposed change to OpenStack against current master of > > k8s-openstack-provider > > 4) A proposed change to OpenStack against stable release of > > k8s-openstack-provider > > > > Those are all easy now that the code is in gerrit, and it's well defined > > what triggers and where it reports. > > > > Additionally, we need to test the surface area between > > k8s-openstack-provider and k8s itself. (if we wind up needing to test > > k8s against proposed changes to OpenStack then we've likely done > > something wrong in life) > > > > 5) A proposed change to k8s-openstack-provider against current master of k8s > > 6) A proposed change to k8s-openstack-provider against a stable release > > of k8s > > 7) A proposed change to k8s against current master of k8s-openstack-provider > > 8) A proposed change to k8s against stable release of k8s-openstack-provider > > > > 5 and 6 are things we can do right now. 7 and 8 will have to wait for GH > > support to land in zuul (without which we can neither trigger test jobs > > on proposed changes to k8s nor can we report the results back to anyone) > > 7 and 8 are going to be pretty important for integrating into the K8S > release process. At the risk of having a work item thrown at me, > is there a target for when that feature will land? >
Hi! Github support is happening basically as "zuulv3+1". We're working on it in parallel with the v3 effort, so it should be a relatively quick +1, but I'd expect infra will need a couple months of shaking out v3 bugs and getting everything ported before we can start talking about hooking infra's zuul up to Github. __________________________________________________________________________ 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
