Add initial Zuul jobs

[mnaser]

No description provided.

[EmilienM]

I could not join the synchronous discussion around that but I just saw this and discussed on Slack with @mnaser . I'm not in favour of adding Zuul to the CI here.
It might be useful for cross repo checks, but the only repo that we would cross-test is Gophercloud. I don't think we'll ever bring back Zuul to Gophercloud CI. We left it years ago (it was OpenLab) because it was always broken and very slow (one hour per job) and now we use Gihut Action, and it's very fast (jobs take no more than 15 minutes total and there are almost no flakes).

So for what my vote is worth, I'm not sure about this PR and I want to know what the plan is on adding Zuul back to the Gophercloud/ORC eco system.

[mnaser]

It might be useful for cross repo checks, but the only repo that we would cross-test is Gophercloud. I don't think we'll ever bring back Zuul to Gophercloud CI. We left it years ago (it was OpenLab) because it was always broken and very slow (one hour per job) and now we use Gihut Action, and it's very fast (jobs take no more than 15 minutes total and there are almost no flakes).

FTR, we don't need to install Zuul in Gophercloud to do cross-repo checks. It can work without it installed there.

[pierreprinetti]

I think we have nothing to lose in investigating the Zuul option and what it can bring to the project. The point here is not to immediately replace the existing CI, which I think is well-dimensioned for ORC at this stage, but rather to enable new ways of testing, for example, the compatibility with other tools compared to Devstack and Kind.

[mnaser]

Alright, if that's the case, I'll look at adding the DevStack jobs next as well and the rest.

[mnaser]

Did a bit of checking, we'll have to leverage devstack-tox-functional-consumer .. but without tox, but we can leverage the roles easily.