Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple volume entries #196

Open
sadlerap opened this issue Dec 16, 2021 · 2 comments
Open

Multiple volume entries #196

sadlerap opened this issue Dec 16, 2021 · 2 comments
Milestone

Comments

@sadlerap
Copy link
Contributor

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.

@scothis scothis added this to the core/1.0.0 milestone Dec 16, 2021
@scothis
Copy link
Member

scothis commented Dec 16, 2021

Adding to the 1.0 milestone so we don't lose track of this

@scothis
Copy link
Member

scothis commented Dec 20, 2021

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

@nebhale nebhale modified the milestones: core/1.0.0, core/post-GA Jan 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants