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

Simple implementation of the tillerless mode #531

Merged
merged 4 commits into from Apr 5, 2019

Conversation

pvalsecc
Copy link
Contributor

@pvalsecc pvalsecc commented Apr 2, 2019

Partial implementation of #449

@pvalsecc pvalsecc force-pushed the tillerless branch 6 times, most recently from 2e6fea4 to fdcaeab Compare April 2, 2019 14:02
@pvalsecc pvalsecc changed the title [WIP] Simple implementation of the tillerless mode Simple implementation of the tillerless mode Apr 2, 2019
@pvalsecc pvalsecc force-pushed the tillerless branch 2 times, most recently from 2daabff to 869ed46 Compare April 3, 2019 05:36
@pvalsecc pvalsecc changed the title Simple implementation of the tillerless mode [WIP] Simple implementation of the tillerless mode Apr 3, 2019
Copy link
Collaborator

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

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.

helmexec/runner.go Show resolved Hide resolved
helmexec/exec.go Outdated Show resolved Hide resolved
@@ -0,0 +1,18 @@
package helmexec

type HelmContext struct {
Copy link
Collaborator

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No can do. execers 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.

Copy link
Collaborator

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!

@pvalsecc
Copy link
Contributor Author

pvalsecc commented Apr 3, 2019

@mumoshu, I just have a pain point, but I don't know if I can fix it. The tillerless mode works only with --concurrency=1 if you have more that one release per tillerNamespace. I've documented this limitation in the readme, but, I don't know if you guys can live with it...

@mumoshu
Copy link
Collaborator

mumoshu commented Apr 3, 2019

@pvalsecc Why is it tied to concurrency=1? Tiller ports' collision?

@pvalsecc
Copy link
Contributor Author

pvalsecc commented Apr 3, 2019

Why is it tied to concurrency=1? Tiller ports' collision?

Yes, I guess... it's not like there was any error message.

@pvalsecc pvalsecc changed the title [WIP] Simple implementation of the tillerless mode Simple implementation of the tillerless mode Apr 3, 2019
@mumoshu
Copy link
Collaborator

mumoshu commented Apr 3, 2019

@pvalsecc Perhaps setting a dedicated HELM_TILLER_PORT value per release works? accordinvg to helm tiller --help it starts from 44134 so... do we need to create one HelmContext per concurrency = goroutine?

@pvalsecc
Copy link
Contributor Author

pvalsecc commented Apr 3, 2019

Yes, I just came to the same conclusion. I'll try tomorrow.

@mumoshu
Copy link
Collaborator

mumoshu commented Apr 3, 2019

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?

@mumoshu
Copy link
Collaborator

mumoshu commented Apr 3, 2019

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.

@pvalsecc
Copy link
Contributor Author

pvalsecc commented Apr 3, 2019

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.

@mumoshu
Copy link
Collaborator

mumoshu commented Apr 3, 2019

All it uses are secrets and you have one set of secrets per release, named after the release

Makes sense. Thanks for your support ☺️

@pvalsecc pvalsecc force-pushed the tillerless branch 2 times, most recently from b587cfa to 495ad79 Compare April 4, 2019 07:39
@pvalsecc
Copy link
Contributor Author

pvalsecc commented Apr 4, 2019

hummm, looks like HELM_TILLER_PORT doesn't work and nobody really cares:
rimusz/helm-tiller#30
helm/helm#3159

@pvalsecc
Copy link
Contributor Author

pvalsecc commented Apr 4, 2019

@mumoshu, IMHO, this PR is ready for your review.

@@ -42,6 +42,7 @@ clean:
.PHONY: clean

pristine: generate fmt
git diff | cat
Copy link
Collaborator

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

Copy link
Contributor Author

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.

Copy link
Collaborator

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 👍

Copy link
Collaborator

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

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/context.go Outdated Show resolved Hide resolved
@@ -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")
Copy link
Collaborator

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?

Copy link
Contributor Author

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... ;-)

Copy link
Collaborator

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)
Copy link
Collaborator

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?

Copy link
Contributor Author

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.

Copy link
Collaborator

@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 contribution @pvalsecc ☺️

@mumoshu mumoshu merged commit 1acd07f into roboll:master Apr 5, 2019
@pvalsecc pvalsecc deleted the tillerless branch April 5, 2019 11:38
@pvalsecc
Copy link
Contributor Author

pvalsecc commented Apr 5, 2019

Thanks for the quick release, @mumoshu !

@mumoshu
Copy link
Collaborator

mumoshu commented Apr 5, 2019

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

@mumoshu
Copy link
Collaborator

mumoshu commented Apr 7, 2019

The PR has been merged 🎉

@pvalsecc
Copy link
Contributor Author

pvalsecc commented Apr 8, 2019

Thanks for the merge and release.

I'd appreciate it if you could take a look

It's already merged :-)

But then there would be more work on the helm-tiller plugin to use that feature. So many layers...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants