Currently, unresolved secrets are ignored by generated providers. The properties are simply left unset.
This leads to unexpected behaviour during creation because often the resources are created at the same time as the secrets leading to a race condition. Some resources are created correctly while others are created with omitted properties where the secrets weren't ready soon enough. These resources will only be fixed in the next reconciliation run, being setup incorrectly until then.
I propose unresolved secrets should result in an error being thrown by the provider and the default retry mechanism being invoked. This way, the provider will not create a resource until the secrets it requires have been created and are set correctly.
I think this would require a change here
|
// We don't want to fail if the secret is not found. Otherwise, we won't be able to delete the |
|
// resource if secret is deleted before. This is quite expected when both secret and resource |
|
// got deleted in parallel. |
|
if resource.IgnoreNotFound(err) != nil { |
|
return errors.Wrapf(err, errFmtCannotGetSecretValue, ref) |
|
} |
|
for key, value := range data { |
|
if err = pavedTF.SetValue(fmt.Sprintf("%s[%s]", tfPath, key), string(value)); err != nil { |
|
return errors.Wrapf(err, "cannot set string as terraform attribute for fieldpath %q", fmt.Sprintf("%s[%s]", tfPath, key)) |
|
} |
|
} |
|
continue |
Unless the resource is in deletion, this error should not be ignored here. We could probably check for a deletion timestamp to handle both cases. What do you think?
Currently, unresolved secrets are ignored by generated providers. The properties are simply left unset.
This leads to unexpected behaviour during creation because often the resources are created at the same time as the secrets leading to a race condition. Some resources are created correctly while others are created with omitted properties where the secrets weren't ready soon enough. These resources will only be fixed in the next reconciliation run, being setup incorrectly until then.
I propose unresolved secrets should result in an error being thrown by the provider and the default retry mechanism being invoked. This way, the provider will not create a resource until the secrets it requires have been created and are set correctly.
I think this would require a change here
upjet/pkg/resource/sensitive.go
Lines 235 to 246 in c1b0e08
Unless the resource is in deletion, this error should not be ignored here. We could probably check for a deletion timestamp to handle both cases. What do you think?