https://pulumi.com logo
Join Slack
Powered by
Hi, I'm testing using new `pulumi preview` functio...
# general
k
Hi, I'm testing using new 
pulumi preview
functionality from the operator. I want to use the 
protect
keyword against certain resources and then for preview to give an unambigious "allowed/forbidden" about a given change - so ideally, a preview that would destroy and replace a protected resource should fail and not retry. By default it seems like the stack continues retrying the preview operation according to the normal backoff/retry timer. Is there a way to configure retry count in the stack definition? I don't see an option in the docs here: https://github.com/pulumi/pulumi-kubernetes-operator/blob/master/docs/stacks.md eg any way to do something like this in a chart?
Copy code
apiVersion: pulumi.com/v1
kind: Stack
[...]
spec:
  preview: {{ .pulumi.preview | default false }}
  retryMaxAttempts: {{ if .pulumi.preview  }}1{{ else }}8{{ end }}
Edit: seems like this may be appropriate, trying it:
Copy code
retryMaxBackoffDurationSeconds: {{ if .pulumi.preview }}120{{ else }}86400{{ end }}
We specifically are using it with ArgoCD, and something else that could let us in particular work around this workflow would be if the stack entered a custom status condition we could handle differently - eg 
RetryingPreviewAfterFailure
distinct from 
RetryingAfterFailure
I'm not sure how often we would want to retry previews - presumably only if there was something blocking execution that needed to be modified externally to the stack, like Pulumi itself missing permissions on the cloud provider?
s
Hi Nikki! I don't know of any immediate workarounds for this, but you can open an issue against this repo: https://github.com/pulumi/pulumi-kubernetes-operator/issues to bring it to the attention of the engineering team 🙂
👍 1
k
Thanks @steep-plastic-74107 I have created an issue here: https://github.com/pulumi/pulumi-kubernetes-operator/issues/1070 If you think any further information would be useful happy to add it.
🙏 1
For anyone interested: setting 
retryMaxBackoffDurationSeconds
doesn't do what I hoped (cause the stack to enter a 'stalled' state after that number of failures). It simply continues retrying after that timeout indefinitely as far as I can see. I think there may not be a Kubernetes-operator-driven way to implement the 'preview pass/fail' workflow we were hoping at the moment.
11 Views
Open in Slack
PreviousNext
Powered by