Tolerations not supported

[svenhakvoort]

Hi, are there any plans to support providing tolerations in addition to nodeAffinity?

Thank you!

[ryanemerson]

Hi @svenhakvoort, it's certainly something we can look into adding.

We also plan to add support for other configurations from the pod spec, such as TopologyPodConstraints, so it would be good if we established a convention for configuring Pod spec components. Currently we allow pod affinity to be configured via spec.affinity, so the question is do we continue to allow top level configuration in a similar manner or nest these fields under an element.

For example, top level:

kind: Infinispan
...
spec:
  affinity:
    ...
  tolerations:
    ...
  topologySpreadConstraints:
    ...

Or nested:

kind: Infinispan
...
spec:
  statefulset:
    affinity:
      ...
    tolerations:
      ...
    topologySpreadConstraints:
      ...

IMO the latter is the more flexible approach going forward, however we will need to transform the existing spec.affinity field if specified.

@rigazilla WDYT?

[svenhakvoort]

Hi @ryanemerson thank you for your reply.

I definitely agree with the second approach being the most flexible since it allows for more specific pod specs on different components if needed. And going from spec.affinity to spec.statefulset.affinity is very minor and to us at least would be no concern at all.

[rigazilla]

IMO the latter is the more flexible approach going forward, however we will need to transform the existing spec.affinity field if specified.

@rigazilla WDYT?

yeah, imo better to go with a nested struct

[ryanemerson]

This configuration will be added under the spec.scheduling element the same as the affinity and priorityClassName fields, e.g.:

kind: Infinispan
...
spec:
  scheduling:
    affinity:
      ...
    tolerations:
      ...
    topologySpreadConstraints:
      ...