feat: allow dot as separator in resource id #105
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR relates to the resource
id
field in a spec like the following (marked by the arrow below):Currently, this field supports the same character set and syntax as other fields like the workload name, resource type, resource class, etc. In this PR we'd like to change it to also support
.
as a separator character in order to support resource provisioners that need relate a resource id to a workload.The example usecase is when we want a resource id to be related to a workload in some way, for example, for example:
example-workload.thing
would be an identifier for a 'thing' relative to the 'example-workload' workload.Alternatives
One alternative is to use the resource type, resource class, or a param to indicate this relation to the resource provisioner.
Resource class is not adequate here, because class is a useful provisioner differentiator: the same 'thing' relation could be returned by different classes with different behaviors over the same relation.
Resource param is not adequate here, because the provisioner that provides id: example-workload.thing may not be capable of handling example-workload.other-thing.
Resource type is not adequate here either because the output type structure of the 'thing' is the same for workload-a and workload-b.
Thus it's most natural to encode this as an id.
Shared resources
This also works well in the case of 2 workloads that want to refer to the same 'thing' relation on the example-workload.