[openstack-dev] [Fuel][CI] recheck/reverify support for Fuel CI jobs

Jay Pipes jaypipes at gmail.com
Fri Nov 20 21:36:14 UTC 2015


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@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@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@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
>



More information about the OpenStack-dev mailing list