Re: [OpenStack-Infra] Access to CI
On Fri, Dec 7, 2018 at 12:08 PM 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 > Why? If you don't already have one, can you not start with the existing role and maybe improve it to fit all needs? This is partially why as tripleo we've started making independent roles so that we can all benefit from them rather than keeping them within a single project repo. I don't think TripleO would have any issues with adding new functionalities or tweaking things so long as it doesn't break backwards compatibility. This is what I was pushing to start the collaboration around the OSA os_tempest role so I don't think namespace collisions are a problem unless you plan on importing an existing code base. > 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’? > > 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. > > Thanks! > Mohammed > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Access to CI
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 ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] Access to CI
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 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’? 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. Thanks! Mohammed ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] [Release-job-failures] Release of openstack-infra/jenkins-job-builder failed
z...@openstack.org wrote: Build failed. - trigger-readthedocs-webhook http://logs.openstack.org/22/22151762d1147da9bbbe9353fe52c6995ab8b658/release/trigger-readthedocs-webhook/48b0996/ : FAILURE in 1m 32s - release-openstack-python http://logs.openstack.org/22/22151762d1147da9bbbe9353fe52c6995ab8b658/release/release-openstack-python/6d983bb/ : SUCCESS in 3m 51s - announce-release http://logs.openstack.org/22/22151762d1147da9bbbe9353fe52c6995ab8b658/release/announce-release/a9ca9ee/ : SUCCESS in 3m 50s - propose-update-constraints http://logs.openstack.org/22/22151762d1147da9bbbe9353fe52c6995ab8b658/release/propose-update-constraints/453d5a1/ : SUCCESS in 3m 21s Looks like the readthedocs integration for JJB is misconfigured, causing the trigger-readthedocs-webhook to fail ? -- Thierry Carrez (ttx) ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
