There was a conversation a while ago around explicitly avoiding the empty namespace - see http://lists.openstack.org/pipermail/openstack-dev/2014-July/041238.html
The approach I have used since is "xenserver: recheck" and "xen: recheck". I think the appropriate command should be "fuel: recheck". Bob > -----Original Message----- > From: Jay Pipes [mailto:jaypi...@gmail.com] > Sent: 20 November 2015 21:36 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Fuel][CI] recheck/reverify support for Fuel CI > jobs > > Why not "recheck fuel" to align with how other OpenStack 3rd party CI > hooks work? See: recheck xen-server or recheck hyper-v > > Best, > -jay > > On 11/20/2015 05:24 AM, Igor Belikov wrote: > > Alexey, > > > > First of all, "refuel" sounds very cool. > > Thanks for raising this topic, I would like to hear more opinions here. > > On one hand, different keyword would help to prevent unnecessary > > infrastructure load, I agree with you on that. And on another hand, > > using existing keywords helps to avoid confusion and provides expected > > behaviour for our CI jobs. Far too many times I've heard questions like > > "Why 'recheck' doesn't retrigger Fuel CI jobs?". > > > > So I would like to hear more thoughts here from our developers. And I > > will investigate how another third party CI systems handle this questions. > > -- > > Igor Belikov > > Fuel CI Engineer > > ibeli...@mirantis.com <mailto:ibeli...@mirantis.com> > > > > > > > > > > > > > >> On 20 Nov 2015, at 16:00, Alexey Shtokolov <ashtoko...@mirantis.com > >> <mailto:ashtoko...@mirantis.com>> wrote: > >> > >> Igor, > >> > >> Thank you for this feature. > >> Afaiu recheck/reverify is mostly useful for internal CI-related fails. > >> And Fuel CI and Openstack CI are two different infrastructures. > >> So if smth is broken on Fuel CI, "recheck" will restart all jobs on > >> Openstack CI too. And opposite case works the same way. > >> > >> Probably we should use another keyword for Fuel CI to prevent an extra > >> load on the infrastructure? For example "refuel" or smth like this? > >> > >> Best regards, > >> Alexey Shtokolov > >> > >> 2015-11-20 14:24 GMT+03:00 Stanislaw Bogatkin > <sbogat...@mirantis.com > >> <mailto:sbogat...@mirantis.com>>: > >> > >> Igor, > >> > >> it is much more clear for me now. Thank you :) > >> > >> On Fri, Nov 20, 2015 at 2:09 PM, Igor Belikov > >> <ibeli...@mirantis.com <mailto:ibeli...@mirantis.com>> wrote: > >> > >> Hi Stanislaw, > >> > >> The reason behind this is simple - deployment tests are heavy. > >> Each deployment test occupies whole server for ~2 hours, for > >> each commit we have 2 deployment tests (for current > >> fuel-library master) and that's just because we don't test > >> CentOS deployment for now. > >> If we assume that developers will rertrigger deployment tests > >> only when retrigger would actually solve the failure - it's > >> still not smart in terms of HW usage to retrigger both tests > >> when only one has failed, for example. > >> And there are cases when retrigger just won't do it and CI > >> Engineer must manually erase the existing environment on slave > >> or fix it by other means, so it's better when CI Engineer > >> looks through logs before each retrigger of deployment test. > >> > >> Hope this answers your question. > >> > >> -- > >> Igor Belikov > >> Fuel CI Engineer > >> ibeli...@mirantis.com <mailto:ibeli...@mirantis.com> > >> > >>> On 20 Nov 2015, at 13:57, Stanislaw Bogatkin > >>> <sbogat...@mirantis.com <mailto:sbogat...@mirantis.com>> > wrote: > >>> > >>> Hi Igor, > >>> > >>> would you be so kind tell, why fuel-library deployment tests > >>> doesn't support this? Maybe there is a link with previous > >>> talks about it? > >>> > >>> On Fri, Nov 20, 2015 at 1:34 PM, Igor Belikov > >>> <ibeli...@mirantis.com <mailto:ibeli...@mirantis.com>> wrote: > >>> > >>> Hi, > >>> > >>> I'd like to inform you that all jobs running on Fuel CI > >>> (with the exception of fuel-library deployment tests) now > >>> support retriggering via "recheck" or "reverify" comments > >>> in Gerrit. > >>> Exact regex is the same one used in Openstack-Infra's > >>> zuul and can be found here > >>> https://github.com/fuel-infra/jenkins- > jobs/blob/master/servers/fuel-ci/global.yaml#L3 > >>> > >>> CI-Team kindly asks you to not abuse this option, > >>> unfortunately not every failure could be solved by > >>> retriggering. > >>> And, to stress this out once again: fuel-library > >>> deployment tests don't support this, so you still have to > >>> ask for a retrigger in #fuel-infra irc channel. > >>> > >>> Thanks for attention. > >>> -- > >>> Igor Belikov > >>> Fuel CI Engineer > >>> ibeli...@mirantis.com <mailto:ibeli...@mirantis.com> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > ___________________________________________________________________ > _______ > >>> OpenStack Development Mailing List (not for usage questions) > >>> Unsubscribe: > >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >>> <http://OpenStack-dev- > requ...@lists.openstack.org/?subject:unsubscribe> > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack- > dev > >>> > >>> > >>> > ___________________________________________________________________ > _______ > >>> OpenStack Development Mailing List (not for usage questions) > >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org > >>> <mailto:OpenStack-dev- > requ...@lists.openstack.org>?subject:unsubscribe > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > ___________________________________________________________________ > _______ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >> <http://OpenStack-dev- > requ...@lists.openstack.org/?subject:unsubscribe> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> > ___________________________________________________________________ > _______ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >> <http://OpenStack-dev- > requ...@lists.openstack.org/?subject:unsubscribe> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> > >> -- > >> --- > >> WBR, Alexey Shtokolov > >> > ___________________________________________________________________ > _______ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: openstack-dev-requ...@lists.openstack.org > >> <mailto:OpenStack-dev- > requ...@lists.openstack.org>?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > ___________________________________________________________________ > _______ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: OpenStack-dev- > requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___________________________________________________________________ > _______ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev- > requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev