Use OpenAPI to set the default ProviderConfig #252
Conversation
This allows us to avoid an extra update call to the API server when new managed resources are created. Signed-off-by: Nic Cope <negz@rk0n.org>
| @@ -367,11 +367,8 @@ func defaultMRManaged(m manager.Manager) mrManaged { | |||
| return mrManaged{ | |||
| ConnectionPublisher: NewAPISecretPublisher(m.GetClient(), m.GetScheme()), | |||
| Finalizer: resource.NewAPIFinalizer(m.GetClient(), managedFinalizerName), | |||
| Initializer: InitializerChain{ | |||
| NewDefaultProviderConfig(m.GetClient()), | |||
There was a problem hiding this comment.
I considered leaving this out of an abundance of caution, because:
- It's a no-op when the ProviderConfigReference is already set.
- Many providers assume the ProviderConfigReference will never be nil
- It's possible that a provider will be built against this library, but forget to generate/apply new CRDs.
I decided to just remove it, given that it's very unlikely anyone using the package manager and our standard build tooling would ever end up accidentally deploying new provider code without also updating their CRDs.
| @@ -139,6 +139,7 @@ type ResourceSpec struct { | |||
| // ProviderConfigReference specifies how the provider that will be used to | |||
| // create, observe, update, and delete this managed resource should be | |||
| // configured. | |||
| // +kubebuilder:default={"name": "default"} | |||
There was a problem hiding this comment.
I didn't know you could give an object here, nice.
I agree. I'm pretty sure for those managed resources the NewDefaultProviderConfig logic will just become a no-op because |
Description of your changes
This allows us to avoid an extra update call to the API server when new managed resources are created.
I have:
make reviewable testto ensure this PR is ready for review.How has this code been tested
I've tested this by building provider-gcp against this commit, and ensuring that
spec.providerConfigRef.nameis defaulted even when the provider is not running.