[08:00:20] morning [08:02:11] morning [08:17:23] o/ [09:48:24] dhinus: I think the tofu refactor patch is completed https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/69 [09:48:51] I would like to merge it as-is, then figure out further refactoring later, so I can switch to other tasks in between [09:48:59] sounds good [09:49:17] my brain is continuing to think about it in the background :) [09:49:23] I have also opened T376110 for your consideration [09:49:24] T376110: tofu-infra: add support for DNS zones created by wmfkeystonehook - https://phabricator.wikimedia.org/T376110 [09:49:51] we have about 3 DNS zones per projects, and I would like to move that away from the keystone hook into tofu [09:49:52] nice [09:50:46] one question: is MR 70 going to cause a massive delete/create because of the rename? [09:51:03] I was thinking you might need https://opentofu.org/docs/v1.6/language/modules/develop/refactoring/ [09:51:09] i.e. the moved{} block [09:51:27] yes the problem with the moved{} block is that it doesn't support for_each loops [09:51:31] that's why the script in the MR [09:51:35] ah yes I see you mentioned "state mv" in the MR [09:51:57] makes sense [09:52:00] I think we can work on this after merging the refactor [09:52:04] sure [09:52:18] the tofu state mv is unavoidable, or at least I don't see how [09:52:25] I +1d the refactor [09:52:43] state mv, I think it's not too bad with the script [09:53:26] I think I will do that next [09:54:20] I'm dropping some further notes in the task, takeaways from the meeting yesterday + some new thoughts I had this morning [09:54:28] ok [09:55:00] but I see no blockers for your MRs [09:57:57] thanks, refactor merged [10:40:11] * dcaro lunch [11:37:18] dhinus: I think https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/70 is ready for review / deploy [11:37:55] I assume the helper script needs to be run _before_ plan/apply, so plan effectively seens a NOOP, right? [11:50:49] yep [11:52:46] I would make a backup of the tfstate before running the script [11:52:58] good idea [11:53:19] in aws, you can enable bucket versioning and that saved me a couple times :) [11:53:43] I'm not sure if that's possible with object storage? [11:53:57] I think I can do `sudo tofu state pull > backup.json` [11:54:26] that should work, or you can directly grab the file from horizon or openstack cli [12:01:23] dhinus: ok, I introduce a backup in the migration script, so there is always a backup file created when running it [12:02:57] nice [12:03:15] are you available now to assist me in case of failure? :-P [12:06:18] I just merged the patch, will run now the migration script for eqiad1 [12:07:03] well, I'll start with codfw1dev [12:11:43] found a typo in the migration script, fixing [12:14:18] ok, migration script run well this time [12:25:46] dhinus: follow up from previous patch https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/74 [13:30:11] arturo: I saw the follow-up patch, sorry for not catching the issue in the first patch :) [14:03:39] not your fault at all :-) if anything, mine [14:04:05] because the state rename, the plan wasn't clear until after the rename was completed [14:04:15] and that's when the diff surfaced [14:05:04] makes sense [15:29:26] arturo dcaro reading https://wikitech.wikimedia.org/wiki/Wikitech/SUL-migration#My_Wikimedia_Developer_Account_username_is_different_from_my_Wikimedia_Unified_Login_(SUL)_one. [15:29:34] "Such Wikitech accounts will be renamed on 30th November 2024." [15:30:02] also "A password reset is only necessary if you want to edit Wikitech between 1 October 2024 and 30 November 2024." [15:31:09] the first item, I don't know what tha means [15:31:42] the accounts with different usernames (like ours) will be renamed automatically, but in 1 month from now [15:31:58] int he meantime I guess we should keep using the old username and pass, but the password reset should work [15:32:09] if it doesn't work for you, it might be similar to T376140 [15:32:09] T376140: Setting new password at wikitech does not work - https://phabricator.wikimedia.org/T376140 [15:32:31] oh I see [15:32:42] I was consistently misreading 30th Novemeber for 30th September [15:33:00] please do not log in with your SUL account if you want the old wikitech account to be merged to the SUL account [15:33:11] since merging accounts is not possible [15:33:24] too late :( we were testing it in a previous meeting [15:33:53] I can now only login via SUL [15:34:03] it's probably possible to manually detach the SUL account and then rename the almost-unused local account, but that takes some manual work [15:34:09] taavi: and because the accounts are not connected, I lost my 2k edits [15:56:56] * arturo offline [16:44:47] Hey folks, stashbot isn't logging [16:45:44] RhinosF1: https://phabricator.wikimedia.org/T376176 [22:32:53] cteam: I have fixed a number of bots that had their OAuth creds break as part of the Wikitech migration today. I have left T376220 for one of y'all to do. That Labslogbot is used by the keystone hooks to create the Nova_Resource namespace pages for new projects. [22:32:54] T376220: Labslogbot needs new SUL OAuth credentials after Wikitech authn changes - https://phabricator.wikimedia.org/T376220