On Fri, May 29, 2020 at 03:18:58PM +0200, Clement Verna wrote:
> On Thu, 28 May 2020 at 14:27, Pierre-Yves Chibon <firstname.lastname@example.org>
> 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
> three actions:
> - Flag commit successfully built in koji, in other words it adds these
> 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 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
> tested that
> or not.
> 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
> 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 it
> needs a
> little investigation.
> I basically see three ways forward with this:
> - We continue with loopabull and we need to check its python3 support,
> 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 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?
Yes but without all the boilerplate needed for each consumer.
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 well.
I don't have a strong opinion here :-)
infrastructure mailing list -- email@example.com
To unsubscribe send an email to firstname.lastname@example.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://email@example.com