servicebinding / spec

Specification for binding services to k8s workloads
https://servicebinding.io
Apache License 2.0
92 stars 35 forks source link

Workload resource binding: defining PodSpecable resources #193

Closed sadlerap closed 2 years ago

sadlerap commented 2 years ago

Under the workload resource mapping section in the spec, it currently reads the following:

A MappingTemplate object MAY define containers, as an array of MappingContainer objects. If not specified, the default MappingContainer MUST be appropriate for mapping to a PodSpec-able resource.

And later:

When a ClusterWorkloadResourceMapping is defined in the cluster matching a workload resource it MUST be used to map the binding that type. If no mapping is available for the type, the implementation MUST treat the workload resource as a PodSpec-able type.

What is meant by PodSpec-able resource/type here? And what is the default behavior here for mapping a PodSpec-able resource?

So far, I've been treating it as "it contains a Pod's template somewhere in its spec", like how a Job or a Deployment does. However, I'm convinced that isn't right, since that interpretation makes both of these statements rather difficult to implement correctly. This is because we don't know where any PodSpec templates live within a workload's CRD, and attempting to any kind of searching for it within a CRD goes against the point of making a workload resource mapping in the first place. This leads me to believe that my initial guess at what a PodSpec-able resource is must be wrong somehow, but I'm at a loss for what else it could mean that makes it possible for this part of the spec to be implemented.

In the context of workload resource binding, the reference implementation says that .spec.template.spec.containers[*] and .spec.template.spec.initContainers[*] are appropriate for a PodSpec-able resource. Where were these specified? And why are they appropriate default values for mapping (as is required in the first quote)?

scothis commented 2 years ago

We're using PodSpecable as a group of Kubernetes resources that have a PodTemplateSpec struct embedded at .spec.template. Resources like Deployment and Job are included, but CronJob is not (it embeds a PodTemplateSpec, but in the different location). The goal of the Custom Resource Mapping section of the spec is to be able to understand enough about the semantics of the target workload to be able to manipulate it safely.

We need to make sure this concept is clear in the spec. Thanks for identifying the gap

nebhale commented 2 years ago

Closed by #209