[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