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.
The predominant method to health check deployments currently is to use the wait features in an action. This requires users to know and specify the ready status condition for the specific resource they are waiting for. In the background the waiting is done through shelling out to kubectl wait. This is overly verbose and should be solved in a simpler way.
Describe the solution you'd like
Given a Zarf package with a health condition set.
When the package is deployed.
Then health checking is run immediately after the deployment and before any actions.
My suggestion is to just copy what Flux is doing as it has been working over the years. This would add two new fields to the components in a Zarf package, a wait and a healthChecks field.
When wait is true we would wait for all the resources applied to the cluster. This is the preferred method that we would want users to use first of all.
The health checks list is a alternative method for those that for some reason want to only health check specific reasons. They may want to do so because all resources may not be kstatus compatible. Alternatively because they are only interested in specific resources.
In the documentation we would push users to first try using wait because it is much simpler and requires less knowledge of the package.
Describe alternatives you've considered
There are not really that many alternatives out there other than kstatus. This solution would allow us to change to some other health checking method in the future if one would appear without changing the user changing configuration.
One way to get information on which objects are deployed for the wait key is to use the releases.releases object from helm (currently ignored) which should give runtime objects for everything deployed.
Is your feature request related to a problem? Please describe.
The predominant method to health check deployments currently is to use the wait features in an action. This requires users to know and specify the ready status condition for the specific resource they are waiting for. In the background the waiting is done through shelling out to
kubectl wait
. This is overly verbose and should be solved in a simpler way.Describe the solution you'd like
My suggestion is to just copy what Flux is doing as it has been working over the years. This would add two new fields to the components in a Zarf package, a
wait
and ahealthChecks
field.When wait is true we would wait for all the resources applied to the cluster. This is the preferred method that we would want users to use first of all.
The health checks list is a alternative method for those that for some reason want to only health check specific reasons. They may want to do so because all resources may not be kstatus compatible. Alternatively because they are only interested in specific resources.
In the documentation we would push users to first try using wait because it is much simpler and requires less knowledge of the package.
Describe alternatives you've considered
There are not really that many alternatives out there other than kstatus. This solution would allow us to change to some other health checking method in the future if one would appear without changing the user changing configuration.
Additional context
Relates to #2203
The text was updated successfully, but these errors were encountered: