You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
We want to be able to modify topology constraints for el-carro resources when running on a multi-zonal cluster. These are defined in the k8s well-known annotations list available https://kubernetes.io/docs/reference/labels-annotations-taints
Describe the solution you'd like
The most straight-forward way to support this from a user perspective would be to simply apply these well-known annotations directly to the instance object (as it is the root resource determining compute and disk elements), and have the operator propagate these down to any created pods/PVCs.
The specific annotations we have in mind are: topology.kubernetes.io/region topology.kubernetes.io/zone
Describe alternatives you've considered
There are some even more fine grained topology annotations which we could consider supporting instead of or in addition to these which target nodes/hostnames.
We could also choose to expose these through some portion of the spec instead, but I suspect its easiest to use if we expose these via annotations similar to how users would interact with a Pod/Deployment.
Additional context
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
We want to be able to modify topology constraints for el-carro resources when running on a multi-zonal cluster. These are defined in the k8s well-known annotations list available https://kubernetes.io/docs/reference/labels-annotations-taints
Describe the solution you'd like
The most straight-forward way to support this from a user perspective would be to simply apply these well-known annotations directly to the
instance
object (as it is the root resource determining compute and disk elements), and have the operator propagate these down to any created pods/PVCs.The specific annotations we have in mind are:
topology.kubernetes.io/region
topology.kubernetes.io/zone
Describe alternatives you've considered
There are some even more fine grained topology annotations which we could consider supporting instead of or in addition to these which target nodes/hostnames.
We could also choose to expose these through some portion of the spec instead, but I suspect its easiest to use if we expose these via annotations similar to how users would interact with a Pod/Deployment.
Additional context
The text was updated successfully, but these errors were encountered: