#8273 Please provide fedora-messaging "consumer" certificate/key for copr-frontend
Closed: Invalid 12 days ago by praiskup. Opened a month ago by praiskup.

We'd like to reliably listen for events on fedora-messaging bus on
copr-fe* VMs, see [1] for more info.

Can we have new messaging config for this purpose? Or should we re-use
the stuff generated for the purpose of copr-backend? (copr-backend is
sending messages while copr-frontend is just listening).

[1] https://pagure.io/copr/copr/pull-request/1025#


If you are just consuming/listening, you can use the public user setup in the 'fedora-messaging' package.

https://fedora-messaging.readthedocs.io/en/stable/configuration.html#id11

The fedora key/cert there lets you talk to a public read-only queue that has the same messages as the real one. :)

Metadata Update from @kevin:
- Issue priority set to: Waiting on Reporter (was: Needs Review)

a month ago

It works but I thought that we should go out with production ready
configuration, meaning that we should have dedicated queues and reliable
delivery.

Previously I misunderstood the configuration, from the default configuration file:

Queue names must be in the normal UUID format: run "uuidgen" and use
the output as your queue name. If your queue is not exclusive, anyone
can connect and consume from it, causing you to miss messages, so do not
share your queue name. Any queues that are not auto-deleted on
disconnect are garbage-collected after approximately one hour.

If you require a stronger guarantee about delivery, please talk to
Fedora's Infrastructure team.

Well, I think that we can work with the "default guarantees" pretty fine if
you claim that guessing UUID isn't easy (I haven't looked at security POV,
I just trust you).

But I'm afraid that we need to have at least the UUID generated in
{{ private }} somewhere, so we don't have to store the UUID in
ansible.git.

@abompard and @jcline might be able to answer this better than me. :)

I'd just make a new queue if you're deploying it with the infra ansible. If you've already got a key/cert for the backend you can just keep using that IMO.

@praiskup Do you have the info you need here? Or can we provide anything more?

I'm not sure we can use the backend's client certs then, hopefully yes -> so closing, and I'll reopen if there's any other problem. Thank you guys!

Metadata Update from @praiskup:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

12 days ago

Login to comment on this ticket.

Metadata