El Carro is a new project that offers a way to run Oracle databases in Kubernetes as a portable, open source, community driven, no vendor lock-in container orchestration system. El Carro provides a powerful declarative API for comprehensive and consistent configuration and deployment as well as for real-time operations and monitoring.
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/regiontopology.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.
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
instanceobject (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/regiontopology.kubernetes.io/zoneDescribe 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