Multiple volume entries
Opened this issue · 2 comments
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.
Adding to the 1.0 milestone so we don't lose track of this
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:
apiVersion: servicebinding.io/v1alpha3
kind: ClusterWorkloadResourceMapping
metadata:
name: # string
generation: # int64, defined by the Kubernetes control plane
...
spec:
versions: # []MappingTemplate
- version: # string
templates: # NEW
- containers: # []MappingContainer, optional
- path: # string (JSONPath)
name: # string (Restricted JSONPath), optional
env: # string (Restricted JSONPath), optional
volumeMounts: # string (Restricted JSONPath), optional
volumes: # string (Restricted JSONPath), optional