Re: [openstack-dev] [Neutron][Third-Party][Infra] Optimize third party resources
On Thu, Jun 12, 2014 at 12:25 PM, Joe Gordon wrote: > > On Jun 12, 2014 9:20 AM, "Jaume Devesa" wrote: > > > > Hello all, > > > > I've just submitted a patch[1] to solve a bug in Neutron. All the > third-party plugins has voted as +1 but Jenkins has refused the patch > because of the '.' dot at the end of the commit summary line. > > > > I know that is my fault, because I should run the ./run_tests.sh -p > after modify the commit message, but: > > > > You can just turn this rule off in neutrons tox.ini file > https://review.openstack.org/99743 > > since the official Jenkins runs more gates, tests and checks than the > rest of third-party Jenkins, wouldn't be better to run third party jobs > after official Jenkins has verified the patch? I think that would relax the > load on the third party infrastructures and maybe they can be more reactive > in the 'good' patches. > > > > > > [1]: https://review.openstack.org/#/c/99679/2 > > > > -- > > Jaume Devesa > > Software Engineer at Midokura > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][Third-Party][Infra] Optimize third party resources
On Jun 12, 2014 9:20 AM, "Jaume Devesa" wrote: > > Hello all, > > I've just submitted a patch[1] to solve a bug in Neutron. All the third-party plugins has voted as +1 but Jenkins has refused the patch because of the '.' dot at the end of the commit summary line. > > I know that is my fault, because I should run the ./run_tests.sh -p after modify the commit message, but: > You can just turn this rule off in neutrons tox.ini file > since the official Jenkins runs more gates, tests and checks than the rest of third-party Jenkins, wouldn't be better to run third party jobs after official Jenkins has verified the patch? I think that would relax the load on the third party infrastructures and maybe they can be more reactive in the 'good' patches. > > > [1]: https://review.openstack.org/#/c/99679/2 > > -- > Jaume Devesa > Software Engineer at Midokura > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][Third-Party][Infra] Optimize third party resources
On 06/12/2014 01:07 PM, Jaume Devesa wrote: > Anita, thanks for the response. My comments inline: > > > >> Well then we are in a situation where development ceases until the third >> party systems respond. Which is not a situation we want to put ourselves >> in. We actually are actively avoiding that situation. >> >> I don't mean to run after the change is merged, but after is verified, > which is the first step. And I don't mean neither that they should vote. So > I don't see that means the development ceases until the third party > respond... > > The failure on the '.' at the end of the commit title is a style test, >> not something the third party tests would run anyway. >> > > Absolutely agree. My point is that third party have had to run two times: > one before the '.' patch and the other one after. And third party opinion > is worthless if Jenkins says -1. Just want to avoid the first run. > > >> Thanks, >> Anita. >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > Regards, > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > That assumes one situation when check tests run, when a new patchset is submitted. There are other situations when check tests run, on jenkins: recheck (which is a requirement on third party systems as well), after a comment has been submitted if the last run of check tests is older than 3 days and also just prior to going into the gate pipeline. Since we have various triggers and paths to merging already for patches, it would slow down the flow of development - particularly around freeze time, when every one wants their patches merged yesterday - to have to wait for third party tests to report back after jenkins has verified. Thanks, Anita. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][Third-Party][Infra] Optimize third party resources
Anita, thanks for the response. My comments inline: > Well then we are in a situation where development ceases until the third > party systems respond. Which is not a situation we want to put ourselves > in. We actually are actively avoiding that situation. > > I don't mean to run after the change is merged, but after is verified, which is the first step. And I don't mean neither that they should vote. So I don't see that means the development ceases until the third party respond... The failure on the '.' at the end of the commit title is a style test, > not something the third party tests would run anyway. > Absolutely agree. My point is that third party have had to run two times: one before the '.' patch and the other one after. And third party opinion is worthless if Jenkins says -1. Just want to avoid the first run. > Thanks, > Anita. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > Regards, -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][Third-Party][Infra] Optimize third party resources
On 06/12/2014 12:20 PM, Jaume Devesa wrote: > Hello all, > > I've just submitted a patch[1] to solve a bug in Neutron. All the > third-party plugins has voted as +1 but Jenkins has refused the patch > because of the '.' dot at the end of the commit summary line. > > I know that is my fault, because I should run the ./run_tests.sh -p after > modify the commit message, but: > > since the official Jenkins runs more gates, tests and checks than the rest > of third-party Jenkins, wouldn't be better to run third party jobs after > official Jenkins has verified the patch? I think that would relax the load > on the third party infrastructures and maybe they can be more reactive in > the 'good' patches. > > > [1]: https://review.openstack.org/#/c/99679/2 > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > Well then we are in a situation where development ceases until the third party systems respond. Which is not a situation we want to put ourselves in. We actually are actively avoiding that situation. The failure on the '.' at the end of the commit title is a style test, not something the third party tests would run anyway. Thanks, Anita. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][Third-Party][Infra] Optimize third party resources
Hello all, I've just submitted a patch[1] to solve a bug in Neutron. All the third-party plugins has voted as +1 but Jenkins has refused the patch because of the '.' dot at the end of the commit summary line. I know that is my fault, because I should run the ./run_tests.sh -p after modify the commit message, but: since the official Jenkins runs more gates, tests and checks than the rest of third-party Jenkins, wouldn't be better to run third party jobs after official Jenkins has verified the patch? I think that would relax the load on the third party infrastructures and maybe they can be more reactive in the 'good' patches. [1]: https://review.openstack.org/#/c/99679/2 -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
