The tofu integration was developed in T365696: Investigate how to run OpenTofu to manage Cloud VPS admin-only resources. As of this writing, the Cloud VPS tofu-infra project mostly covers flavors.
This task is to consider and track work to extend the coverage to pretty much everything admin-defined:
Otherwise they are just manually coded in the database.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| openstack: opentofu: init modules before runnig plan | operations/puppet | production | +1 -0 |
| Title | Reference | Author | Source Branch | Dest Branch | |
|---|---|---|---|---|---|
| routers: consolidate router_interfaces into the same module | repos/cloud/cloud-vps/tofu-infra!27 | aborrero | arturo-220-routers-consolidate | main | |
| data/: add routers for eqiad1 | repos/cloud/cloud-vps/tofu-infra!26 | aborrero | arturo-220-data-add-routers-fo | main | |
| tofu-infra: refactor imports | repos/cloud/cloud-vps/tofu-infra!25 | aborrero | arturo-244-tofu-infra-refactor | main | |
| Draft: tofu-infra: put all networking data in the same yaml file | repos/cloud/cloud-vps/tofu-infra!24 | aborrero | arturo-314-tofu-infra-put-all | main | |
| tofu-infra: define neutron routers | repos/cloud/cloud-vps/tofu-infra!23 | aborrero | arturo-252-tofu-infra-define-n | main | |
| tofu-infra: refactor providers into its own file | repos/cloud/cloud-vps/tofu-infra!22 | aborrero | arturo-172-tofu-infra-refactor | main | |
| data/: introduce eqiad1-r network and subnet information | repos/cloud/cloud-vps/tofu-infra!21 | aborrero | arturo-175-data-introduce-eqia | main | |
| tofu-infra: import codfw1dev subnets | repos/cloud/cloud-vps/tofu-infra!17 | aborrero | arturo-269-tofu-infra-import-c | main | |
| networks: refactor to remove _set indirection and cloudvps keyword | repos/cloud/cloud-vps/tofu-infra!16 | aborrero | arturo-158-networks-refactor-t | main | |
| tofu-infra: introduce Cloud VPS networks for codfw1dev | repos/cloud/cloud-vps/tofu-infra!13 | aborrero | arturo-689-tofu-infra-introduc | main |
aborrero opened https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/13
tofu-infra: introduce Cloud VPS networks for codfw1dev
aborrero merged https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/13
tofu-infra: introduce Cloud VPS networks for codfw1dev
aborrero opened https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/16
networks: refactor to remove _set indirection and cloudvps keyword
aborrero merged https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/16
networks: refactor to remove _set indirection and cloudvps keyword
aborrero opened https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/17
tofu-infra: import codfw1dev subnets
aborrero merged https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/17
tofu-infra: import codfw1dev subnets
aborrero opened https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/21
data/: introduce eqiad1-r network and subnet information
Change #1056117 had a related patch set uploaded (by Arturo Borrero Gonzalez; author: Arturo Borrero Gonzalez):
[operations/puppet@production] openstack: opentofu: init modules before runnig plan
Change #1056117 merged by Arturo Borrero Gonzalez:
[operations/puppet@production] openstack: opentofu: init modules before runnig plan
aborrero merged https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/21
data/: introduce eqiad1-r network and subnet information
aborrero opened https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/22
tofu-infra: refactor providers into its own file
aborrero merged https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/22
tofu-infra: refactor providers into its own file
aborrero opened https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/23
tofu-infra: define neutron routers
aborrero opened https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/24
tofu-infra: put all networking data in the same yaml file
aborrero opened https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/25
tofu-infra: refactor imports
aborrero merged https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/25
tofu-infra: refactor imports
aborrero merged https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/23
tofu-infra: define neutron routers
aborrero opened https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/26
data/: add routers for eqiad1
aborrero merged https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/26
data/: add routers for eqiad1
aborrero closed https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/24
Draft: tofu-infra: put all networking data in the same yaml file
aborrero opened https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/27
routers: consolidate router_interfaces into the same module
aborrero closed https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/27
routers: consolidate router_interfaces into the same module
I'm thinking this over again, and I'm fairly compelled by the fact that resources managed by tofu are in source control with a history.
That said, I know that @fgiunchedi found the current workflow very confusing. Filippo, can you talk about your experience a bit here? One thing I wonder about is how both deployments (codfw1dev and eqiad1) are currently coupled, so if tofu can't apply in codfw1dev then we also can't change things in eqiad1; I'm pretty sure that needs to be changed.
deployments (codfw1dev and eqiad1) are currently coupled, so if tofu can't apply in codfw1dev then we also can't change things in eqiad1; I'm pretty sure that needs to be changed.
+1 for splitting codfw1dev and eqiad1, similarly to what we did in the tofu-provisioning repo (that was created at a later time than the tofu-infra one).
Certainly, I stubbed my toe on the interaction between tofu and cookbooks when working on the project NFS server. Specifically, the wmcs.nfs cookbooks can change DNS service records for the NFS server, e.g. when changing networks. This works when DNS records are not managed by tofu of course. When DNS service records are managed by tofu (e.g. tools, toolsbeta) then the cookbook and tofu step on each other toes, making the cookbook work on some projects but not others. This was my main gripe with the current situation at the time. We ended up un-managing NFS service records for tools tofu as a middle ground solution.
I realize the above may be a corner case, though to me it begs the question: in a world where all/most resources are managed by tofu, what is the story with cookbook interaction or other general programmatic changes to resources we want to do?
We do have an example today with creating new instances: the cookbook AIUI sends a merge request for tofu and then operators merge it. I thought about doing the same for the NFS cookbook, though programmatically editing HCL files is not trivial without hacks (e.g. anchors in the file), creating new instances works fine I think because it is an append operation, not editing files in place.
From the task description the scope here is "admin-defined" resources, I take it this is different than tools tofu-provisioning where a project itself is managed by tofu? Or is "projects managed by tofu" in scope here too?
"admin-defined" resources
I think that admin-defined just means 'things in cloud-vps managed and supported by staff rather than by random users'.