Open Stack

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