-
Notifications
You must be signed in to change notification settings - Fork 228
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: fail on missing secret #1002
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @lukeelten . The change seems reasonable to me.
Is there an issue for this?
No, I don't think there is an issue for that yet. |
@snasovich - can someone from your team review and merge ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kkaempf @mbologna , apologies for missing the ping on this.
@lukeelten , our team doesn't specifically own TFP altogether or Secret resource specifically but I see that we generally return error in case there are no matching resources found. However, there are also examples where the same pattern of returning nil
on "Not Found" errors in used, see
if err != nil { | |
if IsNotFound(err) || IsForbidden(err) { | |
log.Printf("[INFO] Catalog V2 %s not found at cluster %s", name, clusterID) | |
d.SetId("") | |
return nil | |
} | |
return err |
So I'm a little hesitant to change the behavior here as there may be users that rely on it returning nil
instead of error. Could you please submit issue with clear repro steps and link this PR to it so we can gauge regression potential and such.
@cbron @olblak @prachidamle , not sure which team owns Secrets management but heads-up to you on this PR.
@lukeelten is this specific to secrets and not other types ? I agree with @snasovich that an issue describing specifically what situation you are trying to solve would help. As he said, that pattern is fairly common in our codebase, and we should look at changing the wider pattern instead of an isolated instance: https://github.com/search?q=repo%3Arancher%2Fterraform-provider-rancher2%20if%20IsNotFound(err)&type=code |
Moving from Highlander to Platform Team project board, so it doesn't get lost. Please move to final board once an owner has been identified. |
I opened an issue with steps to reproduce. #1337 |
@snasovich I also agree with the assessment that this is a breaking change. But in my opinion you should only apply this pattern to datasources and not to all resources. |
I agree with the OP on this one, using Data resources to ensure that objects exist is an expected pattern when using Terraform. |
The data source
rancher2_secret_v2
does not fail when the referenced secret is not found. Therefore terraform simply runs further and eventually will face an error when the secret is used.The expected behavior is, that terraform stops running and exists with an error when the referenced secret is not found.