Re: [OpenStack-Infra] How do I add a third party CI by ZuulV3?

2018-07-11 Thread Rikimaru Honjo 

Hello Clark,

On 2018/07/12 0:25, Clark Boylan wrote:

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 ,
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.

I got it.
 



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.

Thank you for suggesting.
I readjust my settings according to the policy.




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


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra




Best regards,
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Rikimaru Honjo
E-mail:honjo.rikim...@po.ntt-tx.co.jp


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] How do I add a third party CI by ZuulV3?

2018-07-11 Thread Clark Boylan 
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 
> >> ,
> >> 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

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] How do I add a third party CI by ZuulV3?

2018-07-09 Thread Rikimaru Honjo 

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 ,
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?


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.


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.

Hope this helps,
Clark

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra




--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Rikimaru Honjo
E-mail:honjo.rikim...@po.ntt-tx.co.jp




___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] How do I add a third party CI by ZuulV3?

2018-07-06 Thread James E. Blair 
We could consider hosting a config-project with pipeline definitions for
third-party CI as an optional service folks could use.  It would not,
however, be able to support customized reporting messages or recheck
syntax.

-Jim

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] How do I add a third party CI by ZuulV3?

2018-07-06 Thread Clark Boylan 
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 ,
> 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.

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.

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.

Hope this helps,
Clark

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] How do I add a third party CI by ZuulV3?

2018-07-06 Thread Rikimaru Honjo 

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 ,
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

Best regards,
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Rikimaru Honjo
E-mail:honjo.rikim...@po.ntt-tx.co.jp


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra