elastic-recheck maintenance takeover

Sean Mooney smooney at redhat.com
Tue Aug 11 21:42:03 UTC 2020


does the tool actully need maitance or do we just need to write more queries and submit them to the tool when we hit
a bug. we used to have a strong recommentation that you never recheck a patch without first inspecting why it
failed and when you leave a recheck add a reference to a bug. there was then a futuer recommentation that if we
see the same bug being reject we add an elastic recheck query refernecing the bug(which you were ment to fined if there
was not alredy one) so that if other hit the same error elastic recheck comments letting them know about the know issue.

for example if you look a the nueton docs 
https://docs.openstack.org/neutron/pike/contributor/policies/gerrit-recheck.html

"Please, do not recheck without providing the bug number for the failed job. For example, do not just put an empty
“recheck” comment but find the related bug number and put a “recheck bug ######” comment instead. If a bug does not
exist yet, create one so other team members can have a look. It helps us maintain better visibility of gate failures"

nova used to have a similar doc but i cant find it currently. i think we might have removed it and driected people to
the centralised contibutors guide at some point. the main contibutor guide docs descibe how to add a new recheck query
https://docs.openstack.org/contributors/code-and-documentation/elastic-recheck.html

but i dont think it common knoladge that we should add new queries, file bugs or at a minium state the reason for
the recheck before rechecking as at least in nove we have not pushed contibutors to do this consitently for 2-3 year.
when i first started working on openstack it was common knoladge and the core teams and other explained that you should
avoid doing an empty recheck but the last time i brought this up downstream in ternally only about have of my team knew
that that convention used to exist.


On Tue, 2020-08-11 at 20:16 +0100, Sorin Sbarnea wrote:
>  To be clear, the goal is drive maintenance of the tool, not to "control" it. Working in sync with opende- infra is
> something I assumed.
> 
> As you well said there is a signifiant deployment / operational part which is currently done with puppet, which is for
> good reason managed by opendev team. One of my goals was to simplify that part, migrate to ansible, container
> conversion being part of it. 
> 
> This is highly dependent on opendev and I am confident that I will get the needed help on achieving that goal.
> 
> Sorin
> 
> > On 11 Aug 2020, at 19:53, Jeremy Stanley <fungi at yuggoth.org> wrote:
> > 
> > service relies represent a substantial chunk of our overall "control
> 
> 




More information about the service-discuss mailing list