Exclusive group

[sebastiangaiser]

Is your feature request related to a problem? Please describe.
In #260 the possibility to have exclusive plans was introduced. This is really useful when e.g. upgrading crucial parts of the cluster but unfortunately then prevents parallelism in such upgrades, e.g. upgrading different node groups one by one. This could speed up plans in larger clusters and/or on bigger bare metal nodes with higher reboot times.

Describe the solution you'd like
The exclusive flag should be extended with a string containing e.g. a exclusiveGroup. If the exclusiveGroup is unset the behavior should be the same as it is right now.

Describe alternatives you've considered
Restructure the api to something like this:

spec:
  exclusive:
    enabled: true
    group: my-fancy-group

[brandond]

What if it was just exclusive to nodes matching the selector? That is to say, what if exclusive plans were allowed to run at the same time as long as they select distinct groups of nodes? I think that'd let you run multiple plans at once while still making sure two exclusive plans aren't operating on any of the same nodes.

That would just be a code change, it wouldn't require any changes to the CRD.

[sebastiangaiser]

Hey, thanks for the response. That sounds great 👍🏻

[brandond]

Actually I'm not sure any change is necessary. exclusive is implemented by a PodAntiAffinity on the Job Pod. All it does is prevent pods from different exclusive plans from running on the same node at the same time. It does not prevent pods from different plans from running on different nodes at the same time.

I don't see how this would be doing what you claim it's doing, in terms of

prevent(ing) parallelism in such upgrades, e.g. upgrading different node groups one by one.

Can you confirm that this is actually the source of your problem, and not something else in how you've configured your plans?