add ability to configure and run preflight checks during install, upgrade, and uninstall operations #327
Conversation
…rade, and uninstall operations Signed-off-by: everettraven <[email protected]>
Signed-off-by: everettraven <[email protected]>
|
|
||
| type PreflightFunc func(string, *release.Release) error | ||
|
|
||
| func NewPreflightFunc(name string, pf PreflightFunc) Preflight { |
There was a problem hiding this comment.
Open to naming suggestions here. I'm thinking something like NewPreflightFromPreflightFunc is more suitable but feels long
Going to spend some time looking into how other packages tend to do this to get some inspiration but figured I shouldn't hold getting a PR up for review on this.
| @@ -205,6 +254,25 @@ func (c *actionClient) Install(name, namespace string, chrt *chart.Chart, vals m | |||
| } | |||
| install.ReleaseName = name | |||
| install.Namespace = namespace | |||
|
|
|||
| // TODO: Open Question - should we always run preflight checks if they exist? | |||
There was a problem hiding this comment.
Open to suggestions here.
My thinking behind not running the preflight checks if dry run is specified is because the caller may have a certain expectation of the output with a dry run and including preflight checks in that could pollute the dry run results.
Signed-off-by: everettraven <[email protected]>
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #327 +/- ##
==========================================
+ Coverage 85.06% 85.31% +0.24%
==========================================
Files 19 19
Lines 1346 1559 +213
==========================================
+ Hits 1145 1330 +185
- Misses 125 149 +24
- Partials 76 80 +4 ☔ View full report in Codecov by Sentry. |
| @@ -125,6 +134,39 @@ func NewActionClientGetter(acg ActionConfigGetter, opts ...ActionClientGetterOpt | |||
| return actionClientGetter, nil | |||
| } | |||
|
|
|||
| type Preflight interface { | |||
| Run(string, *release.Release) error | |||
There was a problem hiding this comment.
Instead of passing a string representing whether it's an install/upgrade/uninstall, could we have a struct that implements separate functions for each phase as a no-op by default where a user can provide "overrides" for just the preflight phases they care about. Basically something something similar to controller-runtime's handler.Funcs
|
Closing in favor of putting this directly in operator-controller/rukpak |
Description:
Preflightinterface and ability to configure a slice ofPreflights to run during theactionClientinstall, upgrade, and uninstall operations.actionClientunit tests to test the preflight check implementationMotivation: