servicebinding/spec

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