On Fri, Apr 17, 2020 at 03:14:56PM +0200, Pierre-Yves Chibon wrote: > On Fri, Apr 17, 2020 at 09:22:27AM -0300, Leonardo Rossetti wrote: > > On Fri, Apr 17, 2020 at 8:07 AM Clement Verna > > <[1]cverna@xxxxxxxxxxxxxxxxx> wrote: > > > > Hi all, > > I wanted to start a discussion and possibly some work around automating > > the manual tasks involved in the release engineering work. > > In particular I have in mind the following tasks : > > - processing the unretire package tickets. > > - processing the requests for a new package or a new branch. > > - container base image release. > > Instead of looking at each of these individually I was thinking that it > > might be interesting to look at having an automation framework or > > something like a bot that could be flexible enough to add more tasks or > > process in the future. > > To do that we have different possibilities, one could be to build a bot > > that has a similar architecture than the compose-tracker > > ([2]https://pagure.io/releng/compose-tracker) ie a fedora-messaging > > consumer processing messages. > > Another option is to use loopabull > > ([3]https://github.com/maxamillion/loopabull) to trigger ansible > > playbook on fedora-messaging messages. > > Both solutions are quite similar, but one (loopabull) provides already > > the boilerplate to trigger a script or a function based on messages > > received (a bit like AWS lambda or other serverless framework). We also > > have already a few process automated that way > > ([4]https://pagure.io/Fedora-Infra/loopabull-tasks). > > So I believe that using loopabull might be the best way forward, but I > > would be interested to hear about other ideas :-) > > > > I would lean to use loopabull because it already works in a "reactive way" > > with mq messages and we don't need to write a full application since we > > will be using ansible (which still can be "extended" developing modules > > for complex tasks) - the above script could become a couple of ansible > > modules to be used in a playbook with loopabull. > > I like loopabull, having been pretty much the only one playing with it since > Adam, I think it's a nice and fine tool and we should try leveraging it. > There is one angle where it isn't straight forward to use, it's secrets. > Currently the API tokens the scripts are using are passed as CLI argument when > calling the script. > If we end up needing something like kerberos keytab for example, we may have to > think how to do this and evaluate if loopabull is still a good fit. So another issue around loopabull is that I think Maxamillion said the other day that he's not really been maintining it upstream, so we might have to help out there if we want to keep using it. >> Would it be possible to use ansible vault files for that (using some kind >> of internal ansible API)? Possibly, but it would mean it would need secrets to unlock the vault and we don't use valut for anything else currently. ;( I wonder how hard it would be to move loopabull into openshift... that might also help the secrets thing by allowing it to keep things in openshift secrets... Is loopabull moved to fedora-messaging? Or still fedmsg? Finally, I think we might also add in here: * sync ansible repo from pagure.io on commits to batcave. That might be the easiest way to get it syncing if we move the ansible repo to pagure. Just sync it on every commit message on batcave01. But I guess we should ponder on the best way to do this. kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
