It’s possible for a custom resource that has multiple different pod resources contained within it, such as specifying both a StatefulSet and a Service as a subresource. A real world example of such a resource would be a RabbitMQ cluster (CRD), which appears to have both of these as subresources. Consider the case where I replace the image running with my own image that has extra resources running within these pods (say, for the sake of introducing more observability into pods themselves), and these resources need to bind against an external service. How can I use a spec-based service binding to bind each of these pods?
The problem here is that if a resource has multiple pod resources (e.g. a Service and a StatefulSet) embedded within it, they each have their own .volumes field. If I want to bind against everything here, I need to update every one of these fields. However, with the current spec API, we only can know about one of these fields, and can therefore only update some of the pods managed by this resource. This is because volumes is specified via a restricted jsonpath, instead of a full jsonpath, so we can't know more than one location for a volumes field.
It’s possible for a custom resource that has multiple different pod resources contained within it, such as specifying both a
StatefulSetand aServiceas a subresource. A real world example of such a resource would be a RabbitMQ cluster (CRD), which appears to have both of these as subresources. Consider the case where I replace the image running with my own image that has extra resources running within these pods (say, for the sake of introducing more observability into pods themselves), and these resources need to bind against an external service. How can I use a spec-based service binding to bind each of these pods?The problem here is that if a resource has multiple pod resources (e.g. a
Serviceand aStatefulSet) embedded within it, they each have their own.volumesfield. If I want to bind against everything here, I need to update every one of these fields. However, with the current spec API, we only can know about one of these fields, and can therefore only update some of the pods managed by this resource. This is becausevolumesis specified via a restricted jsonpath, instead of a full jsonpath, so we can't know more than one location for avolumesfield.