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

Reply via email to