On Fri, May 29, 2020 at 03:18:58PM +0200, Clement Verna wrote:
On Thu, 28 May 2020 at 14:27, Pierre-Yves Chibon
Good Morning Everyone,
I know this question has already been raised a few times, but I think we
raise it once more: what do we see as future for loopabull?
It is currently triggered on 4 topics (3 from prod and 1 from stg) to do
- Flag commit successfully built in koji, in other words it adds these
- Flag when the Fedora CI start testing a PR
- Flag when the Fedora CI finished testing a PR (and thus reports
Upstream released yesterday a 0.0.7 release which brings supports for
fedora-messaging (contributed by your servitor).
Looking at the code, it should be python3 compatible, but it doesn't say
specifically in the setup.py and I honestly don't remember if I've
The package has been orphaned in Fedora for over 10 months and has thus
I've had a chat with upstream yesterday and they are still interested in
project but more as a pet project and their time is just like the rest
limited for pet projects these days.
That being said the code base is really quite small and involves
we're already using in other places (python-pika, celery, rabbitmq,
so there isn't really anything new there.
One of its limitation currently is with secrets, how to pass/specify
This is something we could circumvent via ansible-vault or so, but it
I basically see three ways forward with this:
- We continue with loopabull and we need to check its python3 support,
deal with secrets, if we can get it to run in openshift & so on.
- We look for something else, similar. The requirements being:
- Run a task when seeing a message in our message bus
- Handle secrets
- Scalable up/down
- Runnable in openshift is a bonus
- Preferably in a language we can debug (python++, potentially rust)
- We write something that fits our needs and requirements
There is a PR in fedora-messaging to add a 'run' callback that would
let you execute any command, I think that might be a nice solution and I
think it would meet most of the requirements.
 - https://github.com/fedora-infra/fedora-messaging/pull/163
Isn't that the equivalent of having us write a custom fedora-messaging consumer
for each task we want to automate?
In a way I like this, it's simple(r), really straight forward, constraint and
self-contained. There is no risk that a previous task prevents a following one
to be executed.
On the other hand it also means that if we move to, say fed-messaging, in the
future, we will have to convert more consumers.
If that's a trade off we're willing to live with, then I'm ok with it as