You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, Resource objects returned by a ResourceProvider are expected to match up with a template file, e.g. SqlJob.yaml.template. As described in Issue #34, this will cause the operator to create exactly one K8s object. In #34 we aim to support generating multiple K8s objects from a single Resource, but we additionally should support generating zero K8s objects from a Resource. This will enable Adapters to provide no-op Resources, i.e. Resources that do not cause corresponding K8s objects to be created.
This will be useful in several scenarios:
An Adapter wants to provide Resources that some other Adapter will implement, without requiring a hard dependency on other Adapters.
An Adapter wants to provide an optional Resource and expects the end user to optionally provide a template.
An Adapter wants !mermaid etc to render metadata that doesn't correspond to actual K8s objects.
An end users wants to use an Adapter in an environment that doesn't support a specific K8s object.
N.B. it is insufficient to merely support empty templates, as this would create a scenario wherein Adapter updates may break existing deployments. If an Adapter provides a new Resource type but does not provide a template for it, the end user would need to add their own empty template to explicitly ignore the new Resource. Or, if the Adapter does include an empty template, the end user would need to carefully configure their build to prevent this empty template from overwriting their own custom templates, or templates from other Adapters.
For example, an Adapter update may provide a new Acl resource, expecting some other Adapter to implement it. In this case, the Adapter can either 1) bundle an empty template file, and possibly overwrite an end-user's Acl template, or 2) not include a template file, and expect the end-user to add one themselves.
Neither is a good user experience, so I think we need to support Resources with missing templates. Such Resources won't result in a K8s object being created, and won't result in any "template not found" error.
The text was updated successfully, but these errors were encountered:
Currently, Resource objects returned by a ResourceProvider are expected to match up with a template file, e.g.
SqlJob.yaml.template
. As described in Issue #34, this will cause the operator to create exactly one K8s object. In #34 we aim to support generating multiple K8s objects from a single Resource, but we additionally should support generating zero K8s objects from a Resource. This will enable Adapters to provide no-op Resources, i.e. Resources that do not cause corresponding K8s objects to be created.This will be useful in several scenarios:
!mermaid
etc to render metadata that doesn't correspond to actual K8s objects.N.B. it is insufficient to merely support empty templates, as this would create a scenario wherein Adapter updates may break existing deployments. If an Adapter provides a new Resource type but does not provide a template for it, the end user would need to add their own empty template to explicitly ignore the new Resource. Or, if the Adapter does include an empty template, the end user would need to carefully configure their build to prevent this empty template from overwriting their own custom templates, or templates from other Adapters.
For example, an Adapter update may provide a new Acl resource, expecting some other Adapter to implement it. In this case, the Adapter can either 1) bundle an empty template file, and possibly overwrite an end-user's Acl template, or 2) not include a template file, and expect the end-user to add one themselves.
Neither is a good user experience, so I think we need to support Resources with missing templates. Such Resources won't result in a K8s object being created, and won't result in any "template not found" error.
The text was updated successfully, but these errors were encountered: