Skip to content
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

Merged
merged 3 commits into from
Sep 18, 2022

Conversation

rodrigorfk
Copy link
Contributor

@rodrigorfk rodrigorfk commented Aug 11, 2022

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.

@@ -42,6 +42,7 @@ const (
// ReleaseSetSpec is release set spec
type ReleaseSetSpec struct {
DefaultHelmBinary string `yaml:"helmBinary,omitempty"`
EnableLiveOutput *bool `yaml:"enableLiveOutput,omitempty"`
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@@ -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)
Copy link
Contributor

@mumoshu mumoshu Aug 14, 2022

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? 🤔

Copy link
Contributor Author

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

Copy link
Contributor Author

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.

@yxxhero
Copy link
Member

yxxhero commented Aug 14, 2022

@rodrigorfk Thanks very much. Please fix the conflicts.

@yxxhero
Copy link
Member

yxxhero commented Aug 24, 2022

@rodrigorfk Please fix the conflic. Thanks very much.

@rodrigorfk
Copy link
Contributor Author

done @yxxhero , conflicts resolved. Thanks for notifying me.

@rodrigorfk rodrigorfk force-pushed the enable-live-output branch 4 times, most recently from 29b3a5a to ab3ec42 Compare August 29, 2022 10:55
Signed-off-by: Rodrigo Fior Kuntzer <rodrigo@miro.com>
@mumoshu
Copy link
Contributor

mumoshu commented Sep 17, 2022

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

@yxxhero
Copy link
Member

yxxhero commented Sep 17, 2022

@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?

@mumoshu
Copy link
Contributor

mumoshu commented Sep 17, 2022

@yxxhero See https://helm.sh/docs/topics/version_skew/#supported-versions- this reads like helm maintainers don't maintain older minor releases, right?

@yxxhero
Copy link
Member

yxxhero commented Sep 17, 2022

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

@yxxhero
Copy link
Member

yxxhero commented Sep 17, 2022

As of Helm 3, Helm is assumed to be compatible with n-3 versions of Kubernetes it was compiled against.

@mumoshu

@mumoshu
Copy link
Contributor

mumoshu commented Sep 17, 2022

we need to support three minor versions

This is where I'm lost- what's the rationale behind it if we need to maintain support for unmaintained helm minor versions?

@yxxhero
Copy link
Member

yxxhero commented Sep 18, 2022

@mumoshu

  1. Test versions are reduced from 6 to 3, and ci time is greatly reduced
  2. There are many users of the old version of helm. We need to consider that most users will not directly upgrade to the latest version of helm
  3. Only the helm latest version is tested in ci, which maybe will cause the illusion that helmfile only supports the latest version

Thanks very much.

@mumoshu
Copy link
Contributor

mumoshu commented Sep 18, 2022

@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?

@yxxhero
Copy link
Member

yxxhero commented Sep 18, 2022

@mumoshu What you said is reasonable. It's really a problem In this way, I think it's better to do as you say.

pkg/config/global.go Outdated Show resolved Hide resolved
@yxxhero
Copy link
Member

yxxhero commented Sep 18, 2022

@mumoshu WDYT? about this PR.

Signed-off-by: Yusuke Kuoka <ykuoka@gmail.com>
@mumoshu
Copy link
Contributor

mumoshu commented Sep 18, 2022

@yxxhero Thanks for your confirmation! I've fixed the ci workflow accordingly through 47a9838.

Signed-off-by: Yusuke Kuoka <ykuoka@gmail.com>
@yxxhero
Copy link
Member

yxxhero commented Sep 18, 2022

@mumoshu ok. you can assign it to me. you need more to rest.

@mumoshu
Copy link
Contributor

mumoshu commented Sep 18, 2022

@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!

Copy link
Contributor

@mumoshu mumoshu left a 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!

@mumoshu mumoshu merged commit 8408b02 into helmfile:main Sep 18, 2022
@rodrigorfk
Copy link
Contributor Author

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.

@mumoshu
Copy link
Contributor

mumoshu commented Sep 19, 2022

@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!

https://github.com/helmfile/helmfile/releases/tag/v0.146.0

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 21, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants