FBR: Bodhi should stop sending error emails on success, and should start sending error emails on error

[Randy Barlow]

There is a 1-character diff patch on fedmsg-atomic-composer that I'd
like to apply to production to stop us from getting error e-mails
whenever Bodhi succeeds:

https://github.com/fedora-infra/fedmsg-atomic-composer/pull/21

Basically, the logic is exactly backwards on whether the stderr should
be considered an error or info based on the exit code.

If the FBR is approved I will also need someone to review the PR, and
then I'll just make an upstream release and get it deployed.

[Pierre-Yves Chibon]

On Thu, Mar 16, 2017 at 10:17:43AM -0400, Randy Barlow wrote:
>  There is a 1-character diff patch on fedmsg-atomic-composer that
> I'd
>  like to apply to production to stop us from getting error e-mails
>  whenever Bodhi succeeds:
>  
>  https://github.com/fedora-infra/fedmsg-atomic-composer/pull/21
>  
>  Basically, the logic is exactly backwards on whether the stderr should
>  be considered an error or info based on the exit code.
>  
>  If the FBR is approved I will also need someone to review the PR, and
>  then I'll just make an upstream release and get it deployed. 

+1 for me

Pierre

[Kevin Fenzi]

+1. I would like to not get these emails anymore. ;) 

kevin

[Randy Barlow]

I just remembered that I had never upgraded production to version
2017.0:

https://github.com/fedora-infra/fedmsg-atomic-composer/releases/tag/2017.0

This means that if I install 2017.1 (which has the 1-char diff I asked
for an FBR on) it will also be installing those changes.

FWIW, most of those changes are already hotfixed on production, and
2017.0 was primarily made so that we could have a real release on
production rather than a "sudo vim"'d release. There are a couple of
changes from those release notes that I don't think are on production:

* AtomicConsumer now has a config key

  I think this one will also stop some e-mails we get when fedmsg-hub
  is restarted.

* stderr messages are now logged at info and not error level

  This one is where I introduced the exit code problem that my FBR is
  supposed to fix, but note that without this change all stderr was
  logged as an error which is incorrect since many programs use stderr
  for debug/detail statements (including rpm-ostree as we are seeing).
  2017.1 corrects this change to correctly use the exit code.

With this info, are you still +1 on deploying 2017.1 (with the 1-char
diff)? I personally think it's still OK to go, but I wanted to be
forthcoming about the present state before making more changes than I
had written about in my original FBR. If not, some other options:

* We could wait until after the freeze.

* I could continue the tradition of "sudo vim"'ing production and just
  change that log statement to info instead of error.

What say you?

[Kevin Fenzi]

Thanks for the details... 

I am still +1 to updating this, as I think it's better that we have the
known/current version in use rather than some "might be hotfixed"
version. 

kevin

[Pierre-Yves Chibon]

On Fri, Mar 17, 2017 at 12:36:37PM -0600, Kevin Fenzi wrote:
>  Thanks for the details... 
>  
>  I am still +1 to updating this, as I think it's better that we have the
>  known/current version in use rather than some "might be hotfixed"
>  version.  
Same here, even if that makes rolling back harder (meaning we'll need to fix
that version instead of rolling it back if something goes south).

Pierre

[Randy Barlow]

python2-fedmsg-atomic-composer-2017.1-1.fc25.noarch has been installed
on bodhi-backend01, I believe by Kevin. Thanks!

[Kevin Fenzi]

Yep. I applied this saturday night and it's been doing fine...

Thanks for the quick fix.

On 03/20/2017 10:04 AM, Randy Barlow wrote:
>  python2-fedmsg-atomic-composer-2017.1-1.fc25.noarch has been
> installed
>  on bodhi-backend01, I believe by Kevin. Thanks!
>
>
>  _______________________________________________
>  infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
>  To unsubscribe send an email to infrastructure-leave(a)lists.fedoraproject.org