-
Notifications
You must be signed in to change notification settings - Fork 674
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
Add path to invoke update without determining changed CRN data, add validator for name of secrets #4859
Add path to invoke update without determining changed CRN data, add validator for name of secrets #4859
Conversation
|
@@ -73,6 +76,17 @@ func ResourceIBMContainerIngressSecretOpaque() *schema.Resource { | |||
Computed: true, | |||
Description: "Status of the secret", | |||
}, | |||
"update_secret": { | |||
Type: schema.TypeBool, |
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.
we will have issue if you want to update_secret multiple times .
If user add this field for first time and mark update_secret = true it goes a head and update secret but next time when he wants to update again it will not show any diff to apply since update_secret = true already exists in state file.
Generally for this kind of scenario we define "update_secret" as int when user want to change it he will just increment the value
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.
fixed
Update documentation files also respectively |
@@ -34,6 +34,7 @@ Review the argument references that you can specify for your resource. | |||
- `secret_name` - (Required, String) The name of the kubernetes secret. | |||
- `secret_namespace` - (Required, String) The namespace of the kubernetes secret. | |||
- `persistence` - (Bool) Persist the secret data in your cluster. If the secret is later deleted from the command line or OpenShift web console, the secret is automatically re-created in your cluster. | |||
- `update_secret` - (Optional, Integer) This argument is used to force update from upstream secrets manager instance that stores secret. Increment the value to force an update to your Ingress secret for changes made to the upstream secrets manager secret. |
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.
do you mind adding a dash before the fields
below this? I think I forgot to in the initial documentation so it's running into the next line
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.
You can fix the "fields" argument indentation
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.
fixed to be consistent with other definitions that have nested structs
"update_secret": { | ||
Type: schema.TypeInt, | ||
Optional: true, | ||
Default: false, |
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.
Default can't be false for int type
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.
removed - field now has exact same structure as others that fulfill same purpose
"update_secret": { | ||
Type: schema.TypeInt, | ||
Optional: true, | ||
Description: "Updates secret from secrets manager if value is changed (increment each usage)", | ||
}, |
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.
update_secret
is never set in the code with d.Set
. if I get it right, terraform will detect this field as changed on every apply, if the field is not empty.
this can be verified with a test, where you apply the same testAccCheckIBMContainerIngressSecretOpaqueForceUpdate configuration twice.
you can to use d.Set
and update the state after the ingressAPI.UpdateIngressSecret
.
( or if this behaviour works for you, the field can be modified to a boolean. )
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.
I was unable to replicate the behavior you mentioned either by running the test in the code with the same config again or by manually using my own terraform plan/resources. I see the update_secret
field reflected in the state file and terraform doesn't execute an update on a repeat apply of the same config should the variable remain unchanged. I also took a look at the above mentioned field retry_patch_version
whose pattern update_secret
was modeled after and I didn't see any instances of that implementation using the d.set
either. Although even in the case it did update every time that would be acceptable behavior. Please let me know if there are any other concerns.
I also went ahead and updated the tests to validate this behavior:
make testacc TEST=./ibm/service/kubernetes TESTARGS='-run=TestAccIBMContainerIngressSecretOpaque_ForceUpdate'
==> Checking that code complies with gofmt requirements...
TF_ACC=1 go test ./ibm/service/kubernetes -v -run=TestAccIBMContainerIngressSecretOpaque_ForceUpdate -timeout 700m
=== RUN TestAccIBMContainerIngressSecretOpaque_ForceUpdate
--- PASS: TestAccIBMContainerIngressSecretOpaque_ForceUpdate (84.83s)
PASS
ok github.com/IBM-Cloud/terraform-provider-ibm/ibm/service/kubernetes 86.414s
make testacc TEST=./ibm/service/kubernetes TESTARGS='-run=TestAccIBMContainerIngressSecretTLS_BasicForceUpdate'
==> Checking that code complies with gofmt requirements...
TF_ACC=1 go test ./ibm/service/kubernetes -v -run=TestAccIBMContainerIngressSecretTLS_BasicForceUpdate -timeout 700m
=== RUN TestAccIBMContainerIngressSecretTLS_BasicForceUpdate
--- PASS: TestAccIBMContainerIngressSecretTLS_BasicForceUpdate (63.88s)
PASS
ok github.com/IBM-Cloud/terraform-provider-ibm/ibm/service/kubernetes 65.472s
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.
I wasn't sure about this one.
thank you Jared for looking into it!
Users have been looking for way to invoke update on secret without field change to pull in upstream changes from secrets manager instance so the update path was changed to allow such behavior. Users wanted validation on secret name when using terraform to ensure compliance with Kubernetes resource naming scheme.
Community Note
Relates OR Closes #0000
Output from acceptance testing: