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
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.
The text was updated successfully, but these errors were encountered:
I'm not super familiar with the details of the RabbitMQCluster resource, but the service in this case is a v1 Service, which does not create pods.
That said, there is an issue for resources that do define two distinct PodTemplateSpecs. Only one of them can be bound today. A work around would be to have the user create a ServiceBinding where the workload reference is the child resources that should be bound. Workload label selectors are helpful if the name is generated.
we could:
say this is a limitation of the spec (for now) and the situation is not common enough for us to support.
make the custom mappings for each version themselves an array that can target multiple PodTemplateSpec-like structures within a resource, something like:
It’s possible for a custom resource that has multiple different pod resources contained within it, such as specifying both a
StatefulSet
and aService
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 aStatefulSet
) 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 becausevolumes
is specified via a restricted jsonpath, instead of a full jsonpath, so we can't know more than one location for avolumes
field.The text was updated successfully, but these errors were encountered: