My errata https://bodhi.fedoraproject.org/updates/FEDORA-2020-cfbed9c9ff shows in the right column in Test Gating section
Failed to talk to Greenwave.
in red.
That seems not expected and I don't see any explanation about what it means, what it breaks, and how to fix it.
curl -I https://greenwave-web-greenwave.app.os.fedoraproject.org/api/v1.0/policies curl: (60) SSL certificate problem: certificate has expired
I think we should just tell bodhi to use the new URL for greenwave, it's been using this legacy one for a while now...
Proposed fix: https://pagure.io/fedora-infra/ansible/pull-request/172
Looking around, it looks like we'll need to update that certificate. Nagios, waiverdb, bodhi, greenwave are all relying on this domain.
So the symptoms have been fixed by migrating bodhi and greenwave to the newer URL format but the underlying issue (cert expired) has not been fixed.
We may still have to do it. Especially considering it is in the redirect_uris field of the client_secrets.json for waiverdb, so this may impact user's capabilities to login against waiverdb.
redirect_uris
client_secrets.json
Thanks, https://bodhi.fedoraproject.org/updates/FEDORA-2020-cfbed9c9ff now shows that fedora-ci.koji-build.rpminspect.static-analysis was run.
Metadata Update from @smooge: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: groomed, high-trouble, medium-gain
We should setup cert-manager in our openshift and get all these endpoints to use letsencrypt and then it would auto renew them, etc.
Metadata Update from @kevin: - Issue untagged with: groomed, high-trouble, medium-gain - Issue priority set to: Needs Review (was: Waiting on Assignee)
Metadata Update from @kevin: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: groomed, high-gain, medium-trouble
For the record, @pingou 's similar change to the checkcompose group vars was fine and appropriate. I've also updated the default in check-compose's own code. check-compose asks Greenwave for the gating status of a Rawhide compose when it's checking it, and includes that in the report; this was intended as a precursor to actually turning on compose gating (which we still haven't done), the idea being the compose check reports let us see at a glance how often composes are passing or failing the planned gating requirements.
So the symptoms have been fixed by migrating bodhi and greenwave
This still breaks sending waivers with waiverdb-cli:
requests.exceptions.SSLError: HTTPSConnectionPool(host='waiverdb-web-waiverdb.app.os.fedoraproject.org', port=443): Max retries exceeded with url: /api/v1.0/waivers/ (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired (_ssl.c:1108)')))
This may work via bodhi (bodhi updates waive) but I would not be surprised if it does not either.
@pingou : Interesting, bodhi updates waive did indeed work. Thanks for the hint, I wasn't aware of that command yet.
bodhi updates waive
As soon as I can stand up the staging openshift cluster, we can install cert-manager and have it handle these... then roll to prod.
We sent several bodhi updates yesterday where tests were triggered fine, and talking to greenwave worked. Sounds like this got resolved?
The bodhi/greenwave interaction has been fixed quickly after this ticket was opened. The underlying issue still remains and makes waiverdb-cli fail as you reported here :)
Updating the title here so we can find the remaining issue easier.
To update status I have asked our cert provider to try and issue this cert (which for technical reasons is not easy) I will ask them for a status update.
Metadata Update from @kevin: - Issue tagged with: ops
I've again asked for a status update, and I am starting another possible way to get around this.
This is finally fixed. In both staging and prod.
Enjoy!
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.