Open Stack

On Mon, Jul 9, 2018, at 3:31 AM, Rikimaru Honjo wrote:
> Hello Clark,
> 
> Thank you for your information.
> But, sorry, I have some additional questions.
> 
> On 2018/07/07 1:11, Clark Boylan wrote:
> > On Fri, Jul 6, 2018, at 1:49 AM, Rikimaru Honjo wrote:
> >> Hello,
> >>
> >> I'd like to add a third party CI of networking-spp project.[1]
> >> But, I have some question about it.
> >> I'd appreciate it if you give information.
> >>
> >> My wishes are the following:
> >>
> >> * I'd like to run my test on my environment.
> >>     Because my test requires special environment.
> >> * I'm planning that check new patch-sets and run my test by ZuulV3.
> >>
> >> So I built ZuulV3 and nodepool on my environment, and pushed .zuul.yaml
> >> to gerrit.[2]
> >>
> >> But, the following error was returned.
> >> Should I add settings of my third party CI to project-config in this case?
> >> If it is "Yes", is there documents about the way?
> >>
> >> I confirmed <https://docs.openstack.org/infra/system-config/third_party.html>,
> >> but there was no information for ZuulV3.
> >>
> >>> Zuul encountered a syntax error while parsing its configuration in the
> >>> repo openstack/networking-spp on branch master.  The error was:
> >>>
> >>>    Pipelines may not be defined in untrusted repos, they may only be
> >>>    defined in config repos.
> >>
> >>
> >> [1]
> >> https://github.com/openstack/networking-spp
> >>
> >> [2]
> >> https://review.openstack.org/#/c/580561/1
> > 
> > The Zuul config in the projects that OpenStack Infra hosts apply to the OpenStack Zuul instance. Certain aspects of this config must be defined in a trusted repo to protect this instance from unintended (or even malicious) updates in the repos we host. The error you ran into is a case of this.
> > 
> > In particular pipelines define when and how zuul should run jobs so we don't want anyone to be able to update that without review in central trusted config.
> > 
> > As for how to do this for third party CI, your Zuul would need to have its own trusted config (for the same reasons as above, but protecting your Zuul instance not ours). That config will have pipelines defined. If the project is comfortable with it you can define the jobs and playbooks and roles for third party CI in the upstream project. Then you would select to run those jobs in your Zuul's local config and report the results back to Gerrit from there.
> 
> In this case, should I add a part of my settings to openstack-infra/
> project-config?

No you will need to host your own trusted repo.

> 
> > Or if the upstream project wants to keep that data out of tree you can configure all of it in your Zuul config locally. One drawback to hosting the job config upstream would be that changes to the job config can be made without gating them and ensuring that they work (because third party CI can only vote +/-1). This problem is likely less of an issue if reviewers respect the third party CI results.
> 
> In this case, should I put config-projects on local environment and 
> report the test results to review.openstack.org?
> But, in my understanding, "config-projects" in tenant.yaml should be put 
> under the source of the connection which is the target of reporting.
> If my understanding is correct, I think that config-projects can not be 
> prepared locally.

It can be prepared locally using the git driver, https://zuul-ci.org/docs/zuul/admin/drivers/git.html . This is probably the simplest way to start then you can consider hosting your config on a Gerrit or Github at a later time. Chances are if this is a simple setup that the git driver may work long term.

> 
> > I think to start I would mostly keep what you've done, but move the pipeline definitions and project config that says what jobs to run into your Zuul's config.

> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra