Despite workers.resources, we didn't really deprecated the sections used by both celery and kubernetes, as it would make it easier to define a common configuration for both (having the same resources section for both wouldn't make sense). I'm wondering if we should deprecate all workers sections in favour of workers.celery/workers.kubernetes, but for now, I'm more in favour of no than yes, but I think it will be a part of the discussion about what to deprecate.

For now, as we don't have a concrete decision on what to deprecate, I made it in the same way as before.

Okay, I understood the general approach was actually to move all parameters into the specific workers.celery/workers.kubernetes sections. I am not sure if in general same resources really apply for both executor types. But keeping multiple parameters in multiple sections in my view render a lot of complexity of respecting two locations. Would rather propose to make it lean and clear.

Okay, I understood the general approach was actually to move all parameters into the specific workers.celery/workers.kubernetes sections

At the beginning, I think the general approach was to make this common parachute over the celery/kubernetes (as it was somewhere in the related issue), and at the beginning, it didn't add complexity to the chart really. The situation changed dramatically after the Worker Set feature, which made everything much more complex.

But keeping multiple parameters in multiple sections in my view render a lot of complexity of respecting two locations.

I agree that having a common parachute will be more complex from the template perspective, and also, after all, the chart user can just duplicate the value between places if there is a need for the same config for both worker types. At the end, having this complexity might not be worth the effort.

Would rather propose to make it lean and clear.

Agreed. I will make a separate PR for already merged sections with the deprecation of them. Regarding this PR, I can include deprecation in the follow-up or add it here for nodeSelector tomorrow/or during the weekend, so feel free to merge/not merge it in the current state

Merging and until next week when we plan to cus the release there is time to add on-top :-D And if something should be added to 1.20 le me know and I can delay a bit. Plan is to have next release cut starting next week

I guess it depends on how many releases we want to have before 2.0, as I think that moving the rest of the workers to workers.kubernetes/workers.celery will take around a month more looking at the current speed of it (I already prepared most of the PRs, but I'm also testing one by one to make sure that everything is working correctly). So, I think if we have 1.20, 1.21 and then 2.0, we should be good without the need for delaying the 1.20 release