-
Notifications
You must be signed in to change notification settings - Fork 568
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
Simple implementation of the tillerless mode #531
Conversation
2e6fea4
to
fdcaeab
Compare
2daabff
to
869ed46
Compare
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 for your efforts!
Several comments, but LGTM overall
Please notify me once this gets out of WIP, or you feel like wanting an another look.
@@ -0,0 +1,18 @@ | |||
package helmexec | |||
|
|||
type HelmContext struct { |
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 wonder if we can safely merge this into execer
. I have been long thinking that execer
is the "context" and adding an another context "HelmContext" isn't a must? 🤔
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.
No can do. execer
s lifecycle is not tied to the release, but is allocated once per helmfile. And it is used in // per multiple threads. That is why I ended up passing a context to most methods.
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.
Ah that's good point. I dreamed of changing it to use a dedicated execer per release, but turned out it affects a lot of code including tests. Let's use HelmContext for now.
Thanks!
@mumoshu, I just have a pain point, but I don't know if I can fix it. The tillerless mode works only with |
@pvalsecc Why is it tied to concurrency=1? Tiller ports' collision? |
Yes, I guess... it's not like there was any error message. |
@pvalsecc Perhaps setting a dedicated |
Yes, I just came to the same conclusion. I'll try tomorrow. |
Um.. I'm not sure if multiple tillers can safely operate on the same tiller namespace. Does tiller have a kind of exclusive lock on tiller namespace? |
Maybe helmfile should cap concurrency per tiller-namespace to 1. I believe it's fine to run concurrent helm-tillers across different tiller namespaces, though. |
Tiller runs on your local machine, in this mode. All it uses are secrets and you have one set of secrets per release, named after the release. So it should be quite safe to deal with the different releases in parallel. |
Makes sense. Thanks for your support |
b587cfa
to
495ad79
Compare
hummm, looks like HELM_TILLER_PORT doesn't work and nobody really cares: |
@mumoshu, IMHO, this PR is ready for your review. |
@@ -42,6 +42,7 @@ clean: | |||
.PHONY: clean | |||
|
|||
pristine: generate fmt | |||
git diff | cat |
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.
What do we need this for?(Just curious
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.
At work, I have an old version of go that doesn't agree with the autoformatting of the one in circleci. So I needed the actual output of the diff instead of just the list of files.
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.
Got it. Thanks for clarifying 👍
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.
Several nits but LGTM overall! I'll merge this shortly but i'd appreciate it if you could confirm if those nits are valid 😄 :smi
helmexec/exec_test.go
Outdated
@@ -258,7 +286,7 @@ func Test_TestRelease_Flags(t *testing.T) { | |||
var buffer bytes.Buffer | |||
logger := NewLogger(&buffer, "debug") | |||
helm := MockExecer(logger, "dev") | |||
helm.TestRelease("release", "--cleanup", "--timeout", "60") | |||
helm.TestRelease(HelmContext{Tillerless: false}, "release", "--cleanup", "--timeout", "60") |
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.
Nit but can we safely omit Tillerless:false as its the default(zero) value?
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.
What do you mean by "nit"?
OK, thanks. I never did write any go until previous PR... so I'm learning... ;-)
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 for taking your time :)
"Nit" stands for "nitpick" so I mean "I'm hesitant to point out such a small thing even though your PR is awesome overall, but…"
out, err := helm.exec(append([]string{"secrets", "dec", name})...) | ||
preArgs := context.GetTillerlessArgs(helm.helmBinary) | ||
env := context.getTillerlessEnv() | ||
out, err := helm.exec(append(append(preArgs, "secrets", "dec", name), flags...), env) |
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 thought so but please let me confirm - You run helm-tiller because helm-plugin is tied to tiller, even when the actual plugin code(helm-secrets in this case, which doesnt access tiller itself) isnt?
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.
Exactly. Looks like helm, before calling any plugin, tries to talk to its server. Sadly inefficient.
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 contribution @pvalsecc
Thanks for the quick release, @mumoshu ! |
@pvalsecc Thanks for the great work! Also, I've submitted a tiny PR to helm that makes the probe port configurable, which should allow us to support concurrency > 1 I'd appreciate it if you could take a look 😃 |
The PR has been merged 🎉 |
Thanks for the merge and release.
It's already merged :-) But then there would be more work on the helm-tiller plugin to use that feature. So many layers... |
Partial implementation of #449