[08:44:12] hi folks! Another question/brainbounce for https://phabricator.wikimedia.org/T368366 [08:44:44] I have updated the envoy images, and of course a complete rollout is very long (since we have to include all mesh sidecars etc..) [08:44:49] so for envoy, my plan would be [08:45:02] 1) test it with rest/api-gateway first (staging + prod) [08:45:18] 2) select one/two services on wikikube that use the mesh, and upgrade them [08:45:52] 3) file a puppet change to default to the new bookworm image, and let deployers to pick up the change alongside with others [08:46:22] there are services that don't get deployed a lot so those will need a manual intervention, but we can hopefully monitor over time how things go [08:46:33] does it make sense? Any other idea? [09:32:07] elukey: I agree. What I did in the past is sending a mail to ops@ making deployers aware of the diff they might see on next deploy (new image version) and that it's fine to roll that out [09:32:21] I'm not sure if that helped in the past, but it won't hurt [09:33:12] yep +1 to the email, so we'll avoid multiple pings etc.. [09:33:24] okok perfect I'll try to proceed in this way [11:49:19] the above approach SGTM. I am currently using idle time to wonder about a thing that offers an at-a-glance kinda view of "these changes in the deployment charts haven't been pushed yet". I think it might be useful for those not-deployed-often pods [14:26:00] some potential food for thought here about app vs release vs namespace names: https://phabricator.wikimedia.org/T363407#9945024 [18:31:57] anyone have any style rules of thumb to offer for the values.yaml of our modules? some of them use commented-out fields defined as their default values, others use fields defined as `~` with the default (if any) in a comment, others seem to just put all the fields and their default definitions in the base values.yaml file itself? [18:39:52] I personally tend to use the value "override_me". I think it’s explicit enough.