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.
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
+1. I would like to not get these emails anymore. ;)
kevin
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?
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
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
python2-fedmsg-atomic-composer-2017.1-1.fc25.noarch has been installed on bodhi-backend01, I believe by Kevin. Thanks!
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@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org
infrastructure@lists.fedoraproject.org