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? 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. 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
