[11:42:56] <arturo> in our tofu-infra meeting I mentioned that .tfvars files are discouraged. Well, I'm reading now that they are discouraged for _keeping secrets_. Some guides even recommend you gitignore .tfvars files because of this [11:43:23] <arturo> other usages seem perfectly fine, including its main purpose of decoupling data from logic [11:48:22] <dhinus> arturo: I was reading something similar at https://www.terraform-best-practices.com/code-structure [11:48:35] <dhinus> though it was not very clear, and also it's just a single datapoint [14:26:39] <dhinus> I'm syncing the components versions in tools, as I did yesterday in toolsbeta. no impact expected. [14:27:57] <dhinus> only for the ones not in sync with "main": builds-builder, calico, components-api, wmcs-k8s-metrics [14:29:03] <dhinus> oh there's one error that didn't happen in toolsbeta: Error: UPGRADE FAILED: cannot patch "toolforge-buildpacks-phases" with kind Task: admission webhook "webhook.pipeline.tekton.dev" denied the request: mutation failed: cannot decode incoming new object: json: unknown field "name" [14:29:49] <dcaro> dhinus: I found an issue with the script, the diff command does not accept '--wait' and the deploy cookbook passes it [14:30:12] <dhinus> ouch, thanks [14:30:22] <dcaro> oh, interesting error [14:30:30] <dcaro> might be related to crd versions [14:30:35] <dhinus> I will fix the --wait error [14:33:21] <dcaro> Hmm, the tekton webhook was deployed 5 min ago (the pods restarted), so I don't see that log anymore [14:35:46] <dcaro> I can reproduce dumping the current task, and trying to apply it (kubectl apply -f) [14:39:01] <dcaro> hmm, the version that tools shows is the old one [14:39:14] <dcaro> (using v1beta format for the task resource) [14:40:11] <dcaro> dhinus: should I try redeploying the helm chart? [14:40:19] <dhinus> yes please, I'm pushing the fix for --wait [14:41:05] <dcaro> ack, thanks [14:41:16] <dhinus> https://gitlab.wikimedia.org/repos/cloud/toolforge/toolforge-deploy/-/merge_requests/714 [14:48:04] <dcaro> I think that to get builds-builder going I have to i) disable webhook for tasks, ii) update the task resource to the latest version (v1 format), iii) enable the webhook again [14:48:27] <dcaro> sounds ok? [14:49:07] <dcaro> (it's what I did for toolsbeta, and I though I did for tools, but it seems the task was not upgraded somehow :S ) [14:49:41] <dhinus> I opened T388797 to have a trace [14:49:42] <stashbot> T388797: Some toolforge components are running an old version - https://phabricator.wikimedia.org/T388797 [14:50:17] <dhinus> your plan looks good [14:50:38] <dcaro> similar to https://gitlab.wikimedia.org/repos/cloud/toolforge/toolforge-deploy/-/blob/main/components/builds-builder/0.0.121-upgrade_tekton_to_0.59.3.py?ref_type=heads#L50 [14:53:57] <dhinus> nice, I didn't see those py files before [15:32:33] <dhinus> dcaro: anything else to do for builds-builder? I see the correct version now in get_versions.sh [15:42:03] <dcaro> everything ok there, all fixed, I restored the hooks and all [15:42:10] <dcaro> tested a couple builds too [15:46:48] <dhinus> I'll deploy the other components (calico, components-api, wmcs-k8s-metrics) [15:48:41] <dhinus> calico worked fine [15:49:02] <dhinus> components-api failed but it's maybe expected? Failed to render chart: exit status 1: Error: repo donotdeployyet not found [15:49:25] <dhinus> get_versions.sh says it IS deployed though [15:49:48] <dcaro> in tools yep [15:49:52] <dcaro> I have to look into that [15:50:10] <dcaro> we are not deploying in tools (we did a first version) [15:50:16] <dcaro> I might want to start changing that [15:51:32] <dhinus> so we're fine with having the old version 0.0.19 deployed, but we don't want to push newer ones for now? [15:52:59] <dcaro> not to tools (though I might start) [15:53:09] <dcaro> the idea is that it's still changing very fast [15:53:33] <dcaro> so if there's any big changes needed, doing those on tools might be more work than just deploying the latest version [15:53:55] <dhinus> yep makes sense [15:54:08] <dhinus> I wanted to double check if we should remove 0.0.19 or if we can leave it there [15:54:35] <dcaro> we can leave it there for now, I might start deploying the newer versions soon-ish [15:54:38] <dhinus> ack! [15:56:21] <dcaro> dhinus: can I merge https://gitlab.wikimedia.org/repos/cloud/toolforge/toolforge-deploy/-/merge_requests/714 ? I want to deploy components-api [16:01:29] <dhinus> yes sorry didn't see the approve [16:01:32] <dhinus> I'll merge it [16:02:13] <dcaro> ack thanks! [16:04:16] <dhinus> I'll start running the deploy cookbook on tools for the other open MRs [16:04:44] <dhinus> I have a question about the "dev flow" at https://gitlab.wikimedia.org/repos/cloud/toolforge/toolforge-deploy#expected-development-flow [16:04:48] <dcaro> fyi. it work for toolsbeta components-api (running tests now) [16:04:52] <dhinus> (btw thanks for making that diagram, it's been very useful this week!) [16:05:22] <dhinus> in the final section, I see there's "test" both in the developer and the reviewer columns [16:05:33] <dhinus> after "manually run cookbook" [16:06:12] <dcaro> yep, just saw that, usually we don't wait for review the 'bump_version' MRs, unless there's more than just bumping the version (ex. if there's migration scripts, or extra changes in the config) [16:06:58] <dhinus> ok so I can just self-merge. also manual "test" is probably unnecessary if the functional tests pass? [16:07:05] <dhinus> (unless it's a new feature or something) [16:07:11] <dcaro> yep [16:07:19] <dhinus> ok! [16:07:26] <dcaro> if it's a new feature of sorts, you might also want to add a functional tests [16:07:56] <dcaro> I guess that the flow is in it's "safest" version xd [16:15:22] <dhinus> hmm I just realized that I need rebasing all the MRs... but the cookbook did not fail, maybe because it's not using --wait [16:15:38] <dhinus> maybe the cookbook should stop if the branch is not rebased on top of main? [16:15:39] <dcaro> maybe? [16:15:44] <dcaro> yep, that's a good point [16:15:52] <dcaro> or rebase it by default [16:27:09] <topranks> arturo: if you are around could you maybe do a quick review for me? [16:27:15] <topranks> https://gerrit.wikimedia.org/r/c/operations/homer/public/+/1127526 [16:27:16] <arturo> topranks: sure [16:27:23] <topranks> thanks <3 [16:28:35] <arturo> topranks: +1 [16:28:48] <topranks> thanks dude, I'll merge it now and see does that fix it [16:29:36] <arturo> thanks! [16:57:52] * arturo offline [18:16:36] <dhinus> all MRs in toolforge-deploy are deployed and merged. all tests are passing! [18:19:58] <dcaro> \o/ [18:20:32] <dcaro> I deployed a bunch of components-api stuff too without issues (well, except my own tangling of the cli-api and cleaning up old tooldeployments xd, but that was expected) [18:20:49] <dcaro> thanks for that fix, I think that having the right versions will help a lot debugging [18:23:31] <dhinus> you're welcome! [18:24:41] * dhinus offline [18:26:18] <dhinus> (still here: I forgot to merge the last MR!) [18:26:31] <dhinus> done :) [18:34:02] * dcaro off [18:34:05] <dcaro> cya next week!