[11:51:33] <arturo>	 this change I just made to tofu-infra:
[11:51:33] <arturo>	 https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/181
[11:52:12] <arturo>	 I made in 5 minutes. It is a good example of a change that would have been very cumbersome using to perform via the CLI or the horizon panels
[11:52:53] <arturo>	 so today I'm feeling like we should celebrate opentofu :-)
[11:52:55] <arturo>	 other days I hate it
[14:34:19] <dhinus>	 arturo: I think I might be on the "I hate it" camp today :)
[14:34:25] <dhinus>	 I'm working on this MR https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/180
[14:34:35] <dhinus>	 and I'm struggling to find a way to use "import" blocks
[14:34:41] <dhinus>	 any suggestions?
[14:34:44] <arturo>	 let me see
[14:35:12] <arturo>	 I don't see any import block at here: https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/180/diffs
[14:35:23] <dhinus>	 yes because I can't even get the syntax :D
[14:35:35] <arturo>	 oh ok
[14:35:36] <dhinus>	 I tried pushing without it to see the output of the plan
[14:35:39] <arturo>	 I can definitely help with that
[14:35:43] <dhinus>	 and try to derive the import block from that
[14:35:50] <arturo>	 yes, that's good to do
[14:35:58] <arturo>	 example
[14:36:20] <dhinus>	 I could of course add one import block per each resource, but trying to create some kind of for_each is hard
[14:36:31] <arturo>	 no, imports don't support for_each
[14:36:36] <arturo>	 you need to basically hardcode them
[14:36:43] <arturo>	 that's why I usually create a script to generate them
[14:36:58] <arturo>	 actually, let me explore the git history and show concrete examples
[14:37:08] <dhinus>	 yes I was also looking in previous MRs
[14:37:26] <dhinus>	 they do support some form of for_each but maybe it's not worth the effort
[14:37:51] <dhinus>	 "It is also possible to import to resources in child modules, using their paths, and to single instances of a resource with count or for_each set"
[14:37:57] <arturo>	 oh, do they? yes, they do! what they don't support is running in modules, only in the top level root module
[14:38:04] <dhinus>	 I think your auto-generation might be easier
[14:38:34] <arturo>	 https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/blob/82fecad7482322256109ea4bce02d1d64696dc8d/imports.tf
[14:38:53] <arturo>	 this is something I wrote, and indeed uses for_each
[14:38:56] <dhinus>	 yes that's what I meant
[14:39:10] <dhinus>	 I will try to adapt that one, should be pretty similar to what I need
[14:39:48] <arturo>	 but this what back at a time when we where capturing the openstack object ID in the YAML files
[14:39:52] <dhinus>	 I think that's form before the refactor though
[14:40:04] <dhinus>	 *form
[14:40:06] <dhinus>	 *from
[14:40:12] <arturo>	 yeah, exactly
[14:40:29] <arturo>	 and there was a data remapping involved
[14:40:30] <arturo>	 https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/blob/82fecad7482322256109ea4bce02d1d64696dc8d/locals.tf#L136
[14:40:37] <dhinus>	 honestly I'm tempted to just add imports one by one
[14:40:45] <dhinus>	 they're not many, and we can remove them afterwards
[14:40:53] <arturo>	 yes, that would be easier
[14:41:01] <arturo>	 +1 to that idea
[15:00:05] <dhinus>	 ok it took me 4 iterations to get the right ID but it's working :)
[15:00:14] <dhinus>	 now I just have to add all the records and zones
[15:01:21] <dhinus>	 and I have to limit it to eqiad because it's trying to import in codfw as well
[15:05:33] <arturo>	 that last bit, we don't have a way to do it
[15:06:17] <arturo>	 the option is to plan only for eqiad1, merge, apply on eqiad1 only (by hand), the remove the import files from git
[15:13:01] <dhinus>	 yes I think that's fine
[16:22:34] <andrewbogott>	 Can I get a quick +1 on https://gerrit.wikimedia.org/r/c/operations/puppet/+/1135761/1  ? It's just a lint fix
[16:23:45] <taavi>	 andrewbogott: +1
[16:24:02] <andrewbogott>	 thanks!
[16:50:29] <bd808>	 does anyone remember if there is a writeup somewhere of the challenges with getting the `role()` system from ops/puppet to work in Cloud VPS?
[17:03:51] <andrewbogott>	 I don't think I knew it was a challenge
[17:13:45] <bd808>	 andrewbogott: well... we don't support it at all, so that seems like a challenge
[17:14:00] <andrewbogott>	 fair :)
[17:14:15] <bd808>	 By that I mean that there is no way to use `role(foo)` from Horizon
[17:14:46] <bd808>	 other than maybe ...huh. Could you make a profile that internally invoked a role?
[17:15:59] <taavi>	 ooc, what's the use case here? including role hiera?
[17:16:25] <bd808>	 taavi: basically, yes. Trying to think of ways to make beta less broken
[17:17:27] <taavi>	 even if you called role() from somewhere that wouldn't work as we don't include role files in hiera.yaml in cloud
[17:17:47] <bd808>	 as far as I remember the `role()` wrapper function just messes with the hiera lookups, but maybe it does more than that
[17:18:01] <taavi>	 basically _role sets a global variable and includes the relevant clas
[17:18:03] <taavi>	 s
[17:18:17] <taavi>	 and then hiera.yaml in production reads that global variable to pick which files to read
[17:18:30] <taavi>	 but hiera.yaml in cloud vps does not do that
[17:19:30] <andrewbogott>	 it probably could but I'm worried that it would break/rearrange puppet everywhere in surprising ways.
[17:19:50] <andrewbogott>	 But... we could make a special deployment-prep puppetserver that uses a different lookup path?
[17:20:34] <bd808>	 the hysterical raisins of this is that we had hiera stuff before prod and when it was introduced in prod it was done in interesting new ways that we never reconciled
[17:20:56] <andrewbogott>	 (this same difference in lookup path bit mutante yesterday. It's not great)
[17:20:58] <taavi>	 honestly i suspect you'd get more breakage than fixes by including all the role hiera
[17:21:17] <taavi>	 most of that is filled with prod hostnames and such
[17:21:30] <andrewbogott>	 yeah, roles are often extremely specific
[17:21:31] <bd808>	 I think pontoon does basically the different lookup path stuff
[17:21:37] <taavi>	 (agreed it'd be great! it's also a lot of effort to get there)
[17:25:40] <bd808>	 Part of me wants to completely rebuild deployment-prep, another part wants to incrementally improve it, and then there is the just walk away and ignore it urge. #3wolves
[17:41:25] <andrewbogott>	 could deployment-prep be rebuild with pontoon so it's made up of replicas of real production servers?
[17:41:32] <andrewbogott>	 'could' is doing a lot of work there
[18:48:06] <andrewbogott>	 an amazing thing that is happening lately is that when I run 'tofu destroy' in tf-infra-test in codfw1dev it logs me out of my ssh session to the VM. I haven't investigated how/why yet because I'm so surprised every time it happens
[18:49:03] <andrewbogott>	 it also checks to see if the tofuinfratest.codfw1dev.wmcloud.org proxy exists and crashes out if it doesn't, which seems different from what tofu is supposed to do when it finds a missing resource
[18:49:27] <taavi>	 please file a bug for that
[18:50:40] <Rook>	 If tofu can't create something it usually fails quite audibly no? Is it verifying the proxy exists or trying to make it?
[18:52:47] <andrewbogott>	 I'll get this in phab, just a minute...
[18:57:36] <andrewbogott>	 T391718
[18:57:38] <andrewbogott>	 needs tags
[18:57:54] <andrewbogott>	 um, https://phabricator.wikimedia.org/T391718
[18:58:26] <stashbot>	 T391718: tf-infra-test misbehavior in codfw1dev - https://phabricator.wikimedia.org/T391718
[18:59:16] <andrewbogott>	 that task provides an interesting view into the kind of technical bullshit I'll put up with in order to not interrupt my primary task