You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently when deploying a zarf package using the BB extension a series of wait actions are automatically injected to onDeploy.after to wait 10 minutes for each package inside of Big Bang (in order). However this is currently hardcoded with a timeout of 10 minutes - https://github.com/defenseunicorns/zarf/blob/main/src/extensions/bigbang/bigbang.go#L149 . While Big Bang does use a default 10 minute timeout on each package this is customizable, and if I raised it to 15 minutes in Big Bang I would like to also edit it in zarf to match. There are also cases where the 10 minute time period does not line up with Flux's 10 minutes due to dependencies, etc.
Describe the solution you'd like
Allow for customizing the timeout, with a default of 10 minutes. One possibility to implement this:
extensions:
bigbang:
wait_timeout: 900s
Describe alternatives you've considered
Remove the automatic waits from the extension (or allow them to be toggled off) so that I can build my own custom waits. This would also be acceptable, but would be more work for the end user to rebuild the functionality in a clean way.
Additional context
As an aside - the waits as-is are not very functional across upgrades due to timing of flux's reconciliation loop. Zarf will hit the wait functions before flux has actually triggered the upgrade across the packages, meaning that everything is in a ready state (pre-upgrade) and a deploy will almost always succeed quickly, without waiting. Having these type of waits in the extension may lead users to a false sense of security about the deployment, unless they are more robust.
The text was updated successfully, but these errors were encountered:
## Description
This PR makes it so that the Big Bang extension respects and uses the
`onDeploy.defaults.maxTotalSeconds` field during its `onSuccess` actions
to wait for HelmReleases to be ready.
The default time is still ten minutes (600s), but if a default is
specified _and is greater than 600_, it will use that instead.
```yaml
components:
- name: bigbang
extensions:
bigbang:
version: 2.0.0
valuesFiles:
- config/disable-all.yaml
actions:
onDeploy:
defaults:
maxTotalSeconds: 1200 # 20 minutes in seconds
```
## Related Issue
Fixes#1780
## Type of change
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Other (security config, docs update, etc)
## Checklist before merging
- [ ] Test, docs, adr added or updated as needed
- [x] [Contributor Guide Steps](https://github.com/defenseunicorns/zarf/blob/main/CONTRIBUTING.md#developer-workflow) followed
---------
Signed-off-by: razzle <harry@razzle.cloud>
Is your feature request related to a problem? Please describe.
Currently when deploying a zarf package using the BB extension a series of wait actions are automatically injected to
onDeploy.after
to wait 10 minutes for each package inside of Big Bang (in order). However this is currently hardcoded with a timeout of 10 minutes - https://github.com/defenseunicorns/zarf/blob/main/src/extensions/bigbang/bigbang.go#L149 . While Big Bang does use a default 10 minute timeout on each package this is customizable, and if I raised it to 15 minutes in Big Bang I would like to also edit it in zarf to match. There are also cases where the 10 minute time period does not line up with Flux's 10 minutes due to dependencies, etc.Describe the solution you'd like
Allow for customizing the timeout, with a default of 10 minutes. One possibility to implement this:
Describe alternatives you've considered
Remove the automatic waits from the extension (or allow them to be toggled off) so that I can build my own custom waits. This would also be acceptable, but would be more work for the end user to rebuild the functionality in a clean way.
Additional context
As an aside - the waits as-is are not very functional across upgrades due to timing of flux's reconciliation loop. Zarf will hit the wait functions before flux has actually triggered the upgrade across the packages, meaning that everything is in a ready state (pre-upgrade) and a deploy will almost always succeed quickly, without waiting. Having these type of waits in the extension may lead users to a false sense of security about the deployment, unless they are more robust.
The text was updated successfully, but these errors were encountered: