9:33 a.m.
Hello,
On July 4, 2018 2:26 pm, Paul Belanger wrote:
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.
The SF resource manager to update gerrit ACL is different from using the
gerrit interface as it is fully managed through code review in Software Factory.
See this example of an ACL update: https://review.rdoproject.org/r/10152
We could contribute the resource manager to jeepby, but that's a critical
workflow modification. Do you think the openstack-infra would accept this?
Note that branch creation and suppression are also managed by the
resource manager.
For tracability reasons the resource manager is a very important feature, but
perhaps we could adopt the openstack-infra way of doing this instead.
> > 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.
Beside the above concerns, I'd like to note a few other things we need to
be careful about undertaking such a migration.
Using review.openstack.org requires an UbuntuOne account...
review.rdoproject.org is currently configured to use GitHub identity,
but the next version of Software Factory supports openid
(e.g. fedora account system) and SAML2 (e.g. keycloack).
Tripleo-ci users are currently using a config repository to manage
check and gate jobs that need secrets as well as to update the
openstack-periodic pipeline timer to re-schedule the promotion jobs.
Could those users have +3 permissions on a config repository upstream?
We have also been working on new Zuul features[0] to support enqueue and
abort from the REST api[1], Unfortunately the change needed in Zuul
doesn't get much attention. Do you think we could enable them in
openstack-infra zuul? Or are we going to be relying on infra-core
to stop and re-enqueue RDO promotion jobs when needed?
There are lots of pros to doing such migration, but the blockers are
very important. Is there an etherpad we could list and comment on the
pros/cons of this migration?
Best regards,
-Tristan
[0] https://review.openstack.org/#/c/562321/
[0] https://tree.taiga.io/project/morucci-software-factory/us/960