[12:11:58] !log paws variablize nfs entries for paws-dev 78c50a9b3fb836b473351bdabb20607199234262 T326631 [12:12:01] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Paws/SAL [12:12:01] T326631: Setup nfs for paws-dev - https://phabricator.wikimedia.org/T326631 [17:55:38] stw nice! Here's what I have so far for AWX https://gitlab.wikimedia.org/repos/search-platform/sre/tf-wmcs-awx/-/tree/main/ [18:00:54] inflatador: awesome - might be worth adding a lifecycle { ignore_changes = [ image_name ] } block to your openstack_compute_instance_v2 resources. Occasionally WMCS republish/rename images, which may cause an unexpected replacement of the instance. [18:02:18] Also, if you're hosting code in GitLab, GitLab does have a Terraform state storage thing - not sure if it's part of the version WMF is using, but it might be worth investigating if it's a possibility too [18:03:38] https://docs.gitlab.com/ee/user/infrastructure/iac/terraform_state.html [18:03:57] I don't know much about the WMF GitLab (or GitLab in general), so YMMV [18:04:00] Thanks! I do think gitlab is the most logical place for the TF backend if we do adopt terraform more broadly [18:04:23] it says "all tiers", so it's probably not restricted to Enterprise Edition [18:04:39] but the GL docs aren't always great on that front [18:04:44] we used it at my old job and it worked well, but think we were on PaaS/Enterprise gitlab [18:05:22] the folks maintaining it are in #wikimedia-gitlab [18:05:30] AntiComposite: yeah, the docs mention it's configurable by admins too, so I don't know if it's enabled or not. [18:05:49] stw: heads up, just published terraform-provider-cloudvps v0.1.3 which supports importing proxies, the 'resource id' it wants is just the full proxy name including the domain [18:06:01] <3 [18:06:05] {◕ ◡ ◕} [18:06:57] I'll dig into that one later so I can start managing my *.wmflabs.org proxies too (since they're no longer creatable) [18:07:00] sorry it this long, I had the code ready for a while but didn't get around tagging a release since I was kind of hoping I could include puppet prefix support in this one too [18:07:17] can I bribe you into moving you into .wmcloud.org? [18:07:32] yeah, no worries. I'm not moving particularly quickly on WMCS/Terraform stuff either [18:07:44] If there's enough interest I'm happy to open a ticket for the TF backend in gitlab, I'm just pretty new to WMF and don't want to open a ticket if no one else cares besides me [18:07:52] and if you accidentally delete one, we can still make wmflabs.org proxies so no permanent damage [18:08:19] taavi... it's planned, but it's a lot more complicated due to OAuth consumer shenanigans and needs a whole bunch of coordination [18:09:41] inflatador: I created T318360 some time back. as you might have noticed I'm personally not a huge fan of gitlab due to its open core nature and the possibility of vendor lock-in, but that might still be the most viable option at least for now [18:09:42] T318360: Recommended solution for Terraform state backend - https://phabricator.wikimedia.org/T318360 [18:11:30] tbh, the next big wishlist thing I'm hitting is actually some form of secrets management and bootstrapping access to secret storage. I think I'm too used to having IAM instance profiles and SSM Parameter store within AWS 🤣 [18:12:00] yeah, I agree as far as not getting locked in, but TF backends are pretty easy to swap if we need to [18:12:02] That's still on me to figure out what approach I want to take with that, and it might just be "you can't automate *everything*" [18:13:54] stw: iirc we looked into openstack's secret management service (barbican) a while back, but I don't remember what the result of that was. I remember at least that it didn't have a proper horizon dashboard back then, but that might not be that big of a problem anymore since api access is now possible [18:14:55] Yeah, I guess it's dependent on whether or not secrets can be retrieved "without" authentication - or at least authentication based on the instance which is requesting the secret from the API or not [18:15:39] My ideal endpoint here is basically being able to run a command on an instance and retrieve the value of some variable, but for that variable to be protected from everyone/everything except that instance [18:17:51] (reasoning being that if I'm provisioning *everything*, I need some place to store database credentials etc. That could be a private Git repo, but then I need some place to store SSH private keys to clone said Git repo. It could also be something like Hashicorp Vault, but again I need some way of providing an instance auth to grab the secret) [18:18:35] Hence... I might just go down the route that at *some* point I need to take a manual step and not automate absolutely everything :D [18:18:52] yes AWS makes that really easy and afaik OpenStack doesn't have a real equivalent, because it doesn't have "instance roles" [22:46:51]  Can I have a bowling ball Columbia 300 Viz in red white and gray with law bowls over the world