On Tue, Jul 03, 2018 at 11:42:09PM +0200, Alan Pevec wrote:
> > With the zuulv3 migration wrapping up, I wanted to start a thread about 
> > projects
> > that use the package-distgit-check-jobs template. These are projects like:
> >
> >   openstack/cloudkittyclient-distgit
> >
> > I wanted to raise the idea of maybe pushing these projects directly 
> > upstream into
> > git.openstack.org. The main reason would be to leverage the upstream testing
> > infrastructure upstream, and maybe increase adoption of rpm with other
> > openstack teams. It is also one less this we as RDO have to manage on our 
> > own.
> 
> 
> > From a governance POV these could be under an rdoproject team, tripleo or 
> > some
> > other.
> 
> Ideally we would not have one core team but keep them synced with
> maintainers listed in rdoinfo,
> how could that work with distgit in review.o.o ?
> In review.rdo we're using SF resource manager to create gerrit ACL, is
> that manual operation in openstack gerrit?
> 
Yes, we manage ACLs via code review too, so we can create one per distgit or
have a core group.  We bootstrap each ACL with the PTL (or person who created
the projects) then they manage users vi gerrit.

> > To me the main question is around publishing of RPM and DLRN. Given secrets 
> > are
> > now part of zuulv3, is there any external services running that we'd need to
> > worry about?  Could the publishing process be run from openstack-infra 
> > service?
> 
> I would not be comfortable putting CBS Koji certs in openstack-infra.
> Could we instead trigger CBS Koji builds via 3rd party CI in review.rdo ?
> 
Why not comfortable? It the same process as RDO zuul for upstream, no root would
be able to access them.  However, yes, we can setup rdo zuul as 3pci and trigger
CBS builds from a post pipeline if needed. 

> Cheers,
> Alan
_______________________________________________
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

Reply via email to