Thanks for the meeting and sending the notes, adding some that I see missing:

On 11/20 18:04, Arturo Borrero Gonzalez wrote:

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.

** The risk of orphan resources is double: *** They don't free resources *** They currently break scripts/services that rely on entities having a project (ex. iterating VMS, dns leak detection, ...), and are hard to cleanup.

• 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

** Having the cookbooks manage project lifecycle, and track projects in an non-tofu managed but version controlled file (ex. updating a yaml file in the same or another repo on project creation/deletion).

*** A big downside of the cleanup-after-the-fact options is that cleaning up orphaned resources is technically complicated as it requires special manual actions on different services (ex. nova, swift, ceph, trove, designate, proxies, ..., sometimes even direct DB).

• 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).

** And to create on tofu from the cookbook I guess? (as that's current status quo) https://wikitech.wikimedia.org/wiki/Portal:Cloud_VPS/Admin/Projects_lifecycl...

• 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/

---

Cloud-admin mailing list -- cloud-admin@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/cloud-admin.lists.wikimedia.org/