Open Stack

On Fri, Dec 7, 2018, at 11:06 AM, Mohammed Naser wrote:
> Hi everyone,
> 
> We’re in the processing of moving a lot of our internally used Ansible 
> roles to ones which are public.  As a result, we’d like to also add 
> testing coverage for them, however, there’s two issues that we’re seeing
> 
> We’d love to take advantage of the existing infrastructure for CI rather 
> than use some other third party CI service for those roles.  Also, the 
> Gerrit workflow is great and flows perfectly with everything that we do 
> right now.  However, having said that..
> 
> 1) There seems to be some namespace issues which could block us (for 
> example, openstack/ansible-role-container-registry seems to be fairly 
> TripleO opinionated, even running TripleO jobs).  If we wanted to write 
> a similar role, we’d probably have to put another name.. or 
> $some_other_solution

Long term it seems that the setup described in this spec, https://review.openstack.org/#/c/623033/1/specs/opendev-gerrit.rst, would cover your needs. Then you can host things in Gerrit with non conflicting namespaces and use zuul.

> 
> 2) If we don’t host the code in Gerrit and just use GitHub for now 
> (until we can get namespaced projects in Gerrit with OpenDev), then are 
> we allowed to use the current Zuul deployment and resources to run these 
> jobs?  Is there any sort of infrastructure in place to get a ‘yes’ or 
> ‘no’?

The current OpenStack Infra zuul + GitHub situation is all "third party ci" like. Basically we test other projects where they intersect with OpenStack (Kata is more run their tests because the intersection is support from OpenStack Foundation though). One thing we've learned from this is that it can be painful to fully utilize the power of Zuul from the Github side if you don't buy into gating. Job configs can't be loaded from these repos (as they can break easily without gating).

I think this experience may have influenced a perspective (at least with myself) that I'd much rather not deal with Github as an opaque service day to day. That said, perhaps a better evaluation would be through the hosting of a project that would buy into gating from the start so that we can evaluate it under those circumstances.

> 
> I know that the OpenDev effort is moving forward but it might be a 
> little while before there’s something concrete and it’d be nice to be 
> able to use some infrastructure in the meantime, without having to rely 
> on other external services.

My preference here would be to host in Gerrit if we can. Maybe it is feasible to start allowing new projects in new namespaces before we make the OpenDev switch. (This likely needs more thought than I've just given it though). I'm not completely opposed to using this as a one off "can we Github in the way we'd like Zuul to work with Github" test especially if we have an agreement to move to Gerrit once the OpenDev switch does happen. Mostly don't want to have to support this long term if we decide it isn't tenable hence the Gerrit agreement which we know works.

I do think it would be useful to get others' thoughts on this particularly those that may be running Github + Zuul with a gating workflow already (Paul and Clint and Tobias?). Curious what the rest of the Infra team think.

Clark