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

Remove dependency of linkerd-config for control plane components #4915

Merged
merged 43 commits into from
Oct 6, 2020

Conversation

Pothulapati
Copy link
Contributor

Part of #4914

This PR removes the dependency of mounting linkerd-config into control
plane components by making all that information passed through CLI
flags.`

Signed-off-by: Tarun Pothulapati [email protected]

@Pothulapati Pothulapati requested a review from a team as a code owner August 26, 2020 09:32
This PR removes the dependency of mounting `linkerd-config` into control
plane components by making all that information passed through CLI
flags.`

Signed-off-by: Tarun Pothulapati <[email protected]>
Copy link
Member

@adleong adleong left a comment

Choose a reason for hiding this comment

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

Looks good! I have a few minor comments.

controller/cmd/destination/main.go Outdated Show resolved Hide resolved
@@ -42,6 +40,13 @@ func Main(args []string) {
addr := cmd.String("addr", ":8080", "address to serve on")
adminAddr := cmd.String("admin-addr", ":9990", "address of HTTP admin server")
kubeConfigPath := cmd.String("kubeconfig", "", "path to kube config")
controllerNS := cmd.String("controller-namespace", "", "namespace of the linkerd control plane")
Copy link
Member

Choose a reason for hiding this comment

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

I think this is just specifies which namespace to emit kubernetes events to, right? We could just call the flag --namespace. or maybe even get the current namespace from the downward api.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, I went with --controller-namespace as every other component also has it, and helps with consistency?

controller/cmd/identity/main.go Outdated Show resolved Hide resolved
controller/cmd/destination/main.go Outdated Show resolved Hide resolved
controller/cmd/identity/main.go Outdated Show resolved Hide resolved
@adleong
Copy link
Member

adleong commented Aug 26, 2020

It looks like the golden files need to be updated.

Additionally there are some unit test failures related to the way that clock skew allowance is rendered during upgrade. It looks like this has revealed an existing bug where when the clock skew allowance is read from the configmap during upgrade, it is rendered as a protobuf duration instead of as a go duration:

IssuanceLifetime:    idctx.GetIssuanceLifetime().String(),

I think we need to first convert it to a go duration in order to render it correctly.

Protobuf's Duration is different from goland Duration, and hence this
conversion has to be done manually during retrieval. This worked
previously because we were not using that value directly, and were
storing the same value in protobuf format once again (i.e in the
configMap) but now with these duration values being used as flags outside
the configmap, this was discovered.

Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
@@ -587,15 +588,25 @@ func (options *upgradeOptions) fetchIdentityValues(k kubernetes.Interface, idctx
}
}

clockSkewDuration, err := ptypes.Duration(idctx.GetClockSkewAllowance())
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was causing the upgrade tests to fail, as protobuf's duration is different from Duration in golang, we have to manually convert that using this func, if we are using the value directly. I think this wasn't a problem previously because we were again converting it back into protobuf and using it only there.

Copy link
Member

@adleong adleong left a comment

Choose a reason for hiding this comment

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

I notice that the proxy-injector is not updated here. Make sure you update the description of this PR to indicate what the plan is there.

@@ -186,6 +189,11 @@ func TestUpgradeOverwriteIssuer(t *testing.T) {
if id == "ConfigMap/linkerd-config" {
continue
}

if id == "Deployment/linkerd-identity" {
// skip checking identity as `identity-trust-anchor-pem` is overridden, which is passed as a CLI flag
Copy link
Member

Choose a reason for hiding this comment

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

if we wanted to take this a step further, we could verify that that the path is {spec, containers, *, spec, args, *} or whatever and that the diff.b is issuerCerts.caCrt.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Great suggestion! Done 👍

This commit removes linkerd-config dependency in the proxy-injector and
passes all the values through flags

Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
@Pothulapati
Copy link
Contributor Author

Updated this PR to remove the linkerd-config dependency even for proxy-injector.

Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
charts/partials/templates/_helpers.tpl Outdated Show resolved Hide resolved
@alpeb
Copy link
Member

alpeb commented Sep 3, 2020

Nit: can you use list instead of tuple? They're equivalent but only the former appears in the docs.

@adleong
Copy link
Member

adleong commented Sep 28, 2020

I think this will be simpler if we do #5008 first. Then we can use that in inject instead of loading the protobuf config.

@Pothulapati
Copy link
Contributor Author

@adleong 👍 waiting for the new configMap PR's to merge first! :)

Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
@adleong
Copy link
Member

adleong commented Sep 30, 2020

As we discussed, I think it would be helpful to narrow this PR to just focus on inject or to split the inject portions of this PR into a separate PR.

@@ -202,6 +204,13 @@ func TestUpgradeOverwriteIssuer(t *testing.T) {
// Trust root has changed.
continue
}

if id == "Deployment/linkerd-identity" || id == "Deployment/linkerd-proxy-injector" {
if !pathMatch(diff.path, []string{"spec", "template", "spec", "containers", "*", "args", "*"}) || strings.TrimPrefix(diff.b.(string), "-identity-trust-anchors-pem=") != issuerCerts.ca {
Copy link
Member

Choose a reason for hiding this comment

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

  • If there's a diff outside the container args then fail
  • If there's a diff in some of the containers arg, check if that arg's value differs from issuerCerts.ca. What if the diff is not for that particular arg?

Copy link
Member

@alpeb alpeb left a comment

Choose a reason for hiding this comment

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

This looks ok to me, I just had that test question above 👍

Copy link
Member

@adleong adleong left a comment

Choose a reason for hiding this comment

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

This looks pretty good.

I notice that we're using partials.FlagIfNotEmpty in most places to skip rendering the flag if it's empty. But, will these values ever be empty? I believe they all should have default values from the chart or are required values (such as the trust anchors PEM). I think it probably makes more sense to assume that all defaulting logic has already been applied by the time rendering happens and that all of these values have been populated. This way we're not spreading the defaulting logic between the values generation and the control plane component flags.

here, most args have some values by default. This was
not the case with proxy-injector and hence we went down
this route but now that its a separate thing
(and probably uses a ConfigMap), these checks are removed.

Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
@Pothulapati
Copy link
Contributor Author

@adleong That makes sense, and most fields used here are not empty. Also, The reason for adding that helper check function was for proxy-injector, as it had fields that could be nil but now it's not needed anymore as that will be a separate PR.

@@ -259,6 +259,7 @@ github.com/golang/protobuf v1.4.0-rc.1.0.20200221234624-67d41d38c208/go.mod h1:x
github.com/golang/protobuf v1.4.0-rc.2/go.mod h1:LlEzMj4AhA7rCAGe4KMBDvJI+AwstrUpVNzEA03Pprs=
github.com/golang/protobuf v1.4.0-rc.4.0.20200313231945-b860323f09d0/go.mod h1:WU3c8KckQ9AFe+yFwt9sWVRKCVIyN9cPHBJSNnbL67w=
github.com/golang/protobuf v1.4.0/go.mod h1:jodUvKwWbYaEsadDk5Fwe5c77LiNKVO9IDvqG2KuDX0=
github.com/golang/protobuf v1.4.1 h1:ZFgWrT+bLgsYPirOnRfKLYJLvssAegOj/hgyMFdJZe0=
Copy link
Member

Choose a reason for hiding this comment

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

any reason why this needs to be added?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is go.sum which is edited/used by only the go compiler, and this was done automatically. probably because some code paths do not depend on the protobuf pkg anymore. Also, Running go mod tidy on this branch removed some stuff.

Copy link
Member

@adleong adleong left a comment

Choose a reason for hiding this comment

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

I think the change to go.sum can be reverted. Once that is done, I think this is good to go.

Signed-off-by: Tarun Pothulapati <[email protected]>
@Pothulapati Pothulapati merged commit 5e774aa into main Oct 6, 2020
@Pothulapati Pothulapati deleted the tarun/cp-no-configmap branch October 6, 2020 16:49
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.

3 participants