On Mon, 1 Jun 2020 at 15:37, Pierre-Yves Chibon <pingou(a)pingoured.fr> wrote:
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
> 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)
> three actions:
> - Flag commit successfully built in koji, in other words it adds
> to dist-git:
> - 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
> fedora-messaging (contributed by your servitor).
> Looking at the code, it should be python3 compatible, but it
> specifically in the setup.py and I honestly don't remember if I've
> tested that
> or not.
> The package has been orphaned in Fedora for over 10 months and has
> I've had a chat with upstream yesterday and they are still
> project but more as a pet project and their time is just like the
> of us,
> 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
> needs a
> little investigation.
> I basically see three ways forward with this:
> - We continue with loopabull and we need to check its python3
> how to
> 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
> - We write something that fits our needs and requirements
> There is a PR in fedora-messaging to add a 'run' callback that
> let you execute any command, I think that might be a nice solution
> 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
for each task we want to automate?
Yes but without all the boilerplate needed for each consumer.
In a way I like this, it's simple(r), really straight forward,
self-contained. There is no risk that a previous task prevents a following
to be executed.
On the other hand it also means that if we move to, say fed-messaging, in
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
I don't have a strong opinion here :-)
infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
To unsubscribe send an email to
Fedora Code of Conduct:
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines