Hi,
the WMCS team just had a meeting dedicated to tofu-infra [0], workflows, scope, roadmaps and use cases.
This is a summary.
* The current state, and short/mid term roadmaps have been shared, which includes refactoring the tofu-infra repo, and adding support for more stuff, for example quotas.
* It was mentioned that user assignment is maybe not very well tracked in tofu-infra, because that list can be modified at any given time by end users.
* We kind of agreed that the scope of tofu-infra repository [1] is to track state for admin-controlled openstack resources. User-managed resources are explicitly out of the scope of tofu-infra. Tracking Toolforge resources (k8s VMs and such) are also out of the scope this tofu-infra repository.
* There is some controversy regarding tracking projects resources. The project definition itself. There is a real concern with project deletion, because it will leave orphan resources.
* Because the above point, we have been discussing _not_ tracking project definitions in tofu-infra at all. And automate project deletion via a cookbook that takes care of removing potentially orphaned resources.
* Obviously not tracking projects comes with the downside of... well, not having gitops for projects definitions, which is something we kind of want to have.
* We have been discussing potential solutions, including: ** extending wmfkeystonehook to prevent deleting projects if they have resources ** expand our suite of 'leak detector' scripts to report orphaned resources ** having some kind of background daemon automatically cleaning up orphaned resources
* A strong decision on what to do with project definitions has not been made, which implies we should keep the current status quo (they are tracked in tofu-infra).
* We have been discussing ideas and options for integrating tofu-infra with the cookbooks, with a variety of opinions on whether that is convenient or not, or if tofu-infra is ready for building automation on top of it or not, etc.
* It was mentioned the use case, or desire, to enable our clinic-duty workflows for non-technical, non-SRE folks in the organization. While the use case is felt right, some bits should be clarified, because these folks may not have the required access level after all, for example to use cookbooks.
Finally, it was agreed that further discussions should happen on this topic soon.
regards.
[0] https://wikitech.wikimedia.org/wiki/Portal:Cloud_VPS/Admin/OpenTofu [1] https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/