On Mon, 1 Jun 2020 at 15:37, Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> 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 <[1]pingou@xxxxxxxxxxxx>
> wrote:
>
> Good Morning Everyone,
>
> I know this question has already been raised a few times, but I think we
> should
> 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
> basically
> three actions:
> - Flag commit successfully built in koji, in other words it adds these
> flags
> to dist-git:
>
> [2]https://src.fedoraproject.org/rpms/mingw-filesystem/c/717f2a929bd25b62a0427e8e5c3792a0939dbfce
> - Flag when the Fedora CI start testing a PR
> - Flag when the Fedora CI finished testing a PR (and thus reports
> Pass/Fail)
>
> 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
> been
> retired.
>
> I've had a chat with upstream yesterday and they are still interested in
> the
> 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
> technologies
> we're already using in other places (python-pika, celery, rabbitmq,
> ansible...)
> so there isn't really anything new there.
>
> One of its limitation currently is with secrets, how to pass/specify
> them.
> 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[0] 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.
>
> [0] - [3]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 :-)
Pierre
_______________________________________________
infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
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://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx 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://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
