Open Stack

+1 for "fuel: recheck". A nice to have addition would be:
"fuel: recheck verify-fuel-library-tasks"

to retrigger just one failed job.

-- 
Dmitry Borodaenko


On Mon, Nov 23, 2015 at 01:32:35PM +0000, Bob Ball wrote:
> 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:jaypipes at gmail.com]
> > Sent: 20 November 2015 21:36
> > To: openstack-dev at 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
> > > ibelikov at mirantis.com <mailto:ibelikov at mirantis.com>
> > >
> > >
> > >
> > >
> > >
> > >
> > >> On 20 Nov 2015, at 16:00, Alexey Shtokolov <ashtokolov at mirantis.com
> > >> <mailto:ashtokolov at 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
> > <sbogatkin at mirantis.com
> > >> <mailto:sbogatkin at mirantis.com>>:
> > >>
> > >>     Igor,
> > >>
> > >>     it is much more clear for me now. Thank you :)
> > >>
> > >>     On Fri, Nov 20, 2015 at 2:09 PM, Igor Belikov
> > >>     <ibelikov at mirantis.com <mailto:ibelikov at 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
> > >>         ibelikov at mirantis.com <mailto:ibelikov at mirantis.com>
> > >>
> > >>>         On 20 Nov 2015, at 13:57, Stanislaw Bogatkin
> > >>>         <sbogatkin at mirantis.com <mailto:sbogatkin at 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
> > >>>         <ibelikov at mirantis.com <mailto:ibelikov at 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
> > >>>             ibelikov at mirantis.com <mailto:ibelikov at mirantis.com>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > ___________________________________________________________________
> > _______
> > >>>             OpenStack Development Mailing List (not for usage questions)
> > >>>             Unsubscribe:
> > >>>             OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > >>>             <http://OpenStack-dev-
> > request at 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-request at lists.openstack.org
> > >>>         <mailto:OpenStack-dev-
> > request at 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-request at lists.openstack.org?subject:unsubscribe
> > >>         <http://OpenStack-dev-
> > request at 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-request at lists.openstack.org?subject:unsubscribe
> > >>     <http://OpenStack-dev-
> > request at 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-request at lists.openstack.org
> > >> <mailto:OpenStack-dev-
> > request at 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-
> > request at 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-
> > request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev