-
-
Notifications
You must be signed in to change notification settings - Fork 240
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
feat: show live output from the Helm binary #286
Conversation
23117c9
to
22e06cc
Compare
pkg/state/state.go
Outdated
@@ -42,6 +42,7 @@ const ( | |||
// ReleaseSetSpec is release set spec | |||
type ReleaseSetSpec struct { | |||
DefaultHelmBinary string `yaml:"helmBinary,omitempty"` | |||
EnableLiveOutput *bool `yaml:"enableLiveOutput,omitempty"` |
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 believe this is more like an operational feature than a part of helm releases declared in helmfile.yaml. helmfile.yaml is meant to contain anything for helm releases that are to be templated/diffed/applied/linted by helmfile, but how commands like helm/diff/apply/lint/etc are run.
That said, can we remove this from ReleaseSetSpec and provide it as a command-line flag only, so that it's more consistent with other operational flags?
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.
Hi @mumoshu , thanks for the feedback and for taking the time to explain the concept around operational flags, completely understood and definitely make sense, I will address your suggested change shortly and will circle back here once done.
22e06cc
to
b072c56
Compare
pkg/helmexec/exec.go
Outdated
@@ -484,7 +490,7 @@ func (helm *execer) exec(args []string, env map[string]string) ([]byte, error) { | |||
} | |||
cmd := fmt.Sprintf("exec: %s %s", helm.helmBinary, strings.Join(cmdargs, " ")) | |||
helm.logger.Debug(cmd) | |||
outBytes, err := helm.runner.Execute(helm.helmBinary, cmdargs, env) | |||
outBytes, err := helm.runner.Execute(helm.helmBinary, cmdargs, env, helm.enableLiveOutput) |
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 believe there are some execer methods that needs to return the whole output to be consumed by the caller, like execer.List
.
For example, the List
method returns the whole helm-list output so that the caller can use it to decide if a helm release is already installed onto the cluster or not, which affects what helmfile sync
and helmfile apply
do when the release exists in the cluster and is requested to be uninstalled by setting installed: false
in helmfile.yaml like:
releases:
- name: myapp
# This instructs Helmfile to uninstall the release by running `helm uninstall myapp` if `helm list` output showed the `myapp` release as installed
installed: false
Perhaps we'd need to make the enableLiveOutput flag a parameter to the execer.exec
function, so that each caller execer
function can decide which value to be provided to exec
, either helm.enableLiveOutput
or a hard-coded false
. WDYT? 🤔
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.
thanks again for the heads up @mumoshu, I have followed your recommendation and added the ability of the caller to override the enableLiveOutput
when calling execer.exec
by adding a new pointer parameter, callers that want to explicitly disable live output will pass it as a reference for a hard-coded false
, other callers that don't care about it, will pass it as a nil
, and then helm.enableLiveOutput
will be used by default inside the execer.exec
function
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.
Hi @mumoshu, sorry for the direct mention here, but I just want to check your opinion about the final implementation in this PR, do you believe is it good enough? do you suggest any change or further tests? thanks in advance.
@rodrigorfk Thanks very much. Please fix the conflicts. |
b072c56
to
30b7f7b
Compare
30b7f7b
to
2fa3e6e
Compare
2fa3e6e
to
9fc4829
Compare
@rodrigorfk Please fix the conflic. Thanks very much. |
9fc4829
to
0aa6a9c
Compare
done @yxxhero , conflicts resolved. Thanks for notifying me. |
29b3a5a
to
ab3ec42
Compare
ab3ec42
to
6d0adfe
Compare
6d0adfe
to
d8f7ce2
Compare
Signed-off-by: Rodrigo Fior Kuntzer <rodrigo@miro.com>
d8f7ce2
to
57e6cd8
Compare
Sorry for the delayed review/merge and for requiring you to resolve conflicts so many times. There're another conflicts now but let me do the resolution this time @rodrigorfk |
@mumoshu we only test helm 3.9 in ci? I think if we test tree minor version will be better? 3.7.x 3.8.x 3.9.x? |
@yxxhero See https://helm.sh/docs/topics/version_skew/#supported-versions- this reads like helm maintainers don't maintain older minor releases, right? |
maybe: Applicable fixes, including security fixes, are cherry-picked into the release branch, depending on severity and feasibility. In addition, I think the version release strategy of helm should not conflict with the version of HELM we want to support. Generally speaking, we need to support three minor versions. I remember this is the default behavior of open source projects. WDYT? @mumoshu |
As of Helm 3, Helm is assumed to be compatible with n-3 versions of Kubernetes it was compiled against. |
This is where I'm lost- what's the rationale behind it if we need to maintain support for unmaintained helm minor versions? |
Thanks very much. |
@yxxhero The last question from my side- doesn't that result in giving our users an illusion that you can "safely" use older helm minor versions? In reality, old helm releases don't even seem to get security patches. Then, regardless of Helmfile supports older helm minor releases or not, you must upgrade Helm to the latest ASAP. Helmfile should not advocate uses of older Helm minor releases. Instead, it should guide users to upgrade Helm earlier. What if we maintain compatibility with not 3 but 2 helm versions, the latest maintained releases, and the latest unmaintained release? Would that be enough to cover the time needed to upgrade Helm? |
@mumoshu What you said is reasonable. It's really a problem In this way, I think it's better to do as you say. |
@mumoshu WDYT? about this PR. |
Signed-off-by: Yusuke Kuoka <ykuoka@gmail.com>
6adebfd
to
47a9838
Compare
Signed-off-by: Yusuke Kuoka <ykuoka@gmail.com>
@mumoshu ok. you can assign it to me. you need more to rest. |
@yxxhero Thanks for your kind words! I believe this one is ready to be merged. But it would be definitely great if you could handle other issues/prs! |
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.
LGTM. Thanks a lot for your patience and contribution @rodrigorfk!
thank you @mumoshu for all the support and suggestions during the review process here, it was an amazing experience being part of it and seeing how a constructive and transparent discussion took place, well done you all. as a final question from my side: how frequently do you ship a new release covering the last added features? I saw the latest version was released 5 days ago, is there any new release planned? thanks in advance. |
@rodrigorfk Thank you so much for your contribution and kind words! This is absolutely a kind of collaboration that motivates us, maintainers, ❤️ I've just released v0.146.0 for this and other enhancements made since the last patch release. It would be awesome if you could give it a shot and leave any comments/feedback if anything added in the release doesn't work for you! |
This PR addresses what has been discussed here: #283
To enable some workflows where is interesting to have the stdout/stderr output of the Helm binary being shown live in the Helmfile output, the
--enable-live-output
global flag can now be provided to switch the default behaviour from Helmfile, which is to show the output from the Helm binary only after the command has completed.