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

discover in cluster namespace for leader election #24

Merged

Conversation

andrewsykim
Copy link
Contributor

Signed-off-by: Andrew Sy Kim [email protected]

Adds support to discover namespaces in cluster by checking the env var POD_NAMESPACE, then the file /var/run/secrets/kubernetes.io/serviceaccount/namespace (should exist in every pod). Falls back to default.

@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Apr 1, 2019
@k8s-ci-robot k8s-ci-robot requested review from pohly and saad-ali April 1, 2019 17:51
@andrewsykim
Copy link
Contributor Author

/assign @msau42 @jsafrane

@k8s-ci-robot k8s-ci-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Apr 1, 2019
// inClusterNamespace returns the namespace in which the pod is running in by checking
// the env var POD_NAMESPACE, then the file /var/run/secrets/kubernetes.io/serviceaccount/namespace.
// if neither returns a valid namespace, the "default" namespace is returned
func inClusterNamespace() string {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I prefer not to fall back to default here and just return an error. I left the fallback to default for now since this is used in external-provisioner. Do we know of any situations where a sidecar wouldn't run in the cluster? If not I think the fallback to default should be removed and instead exit with error

Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we say that for Lease mechanism (which should be all new), require a namespace field to be set if not found, but for the other two, we allow the default for backwards compatibility?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We could, though the implementation will be a bit messy I think. I added the WithNamespace method for the cases where we need to account for backwards compatibility. I guess the this boils down to two questions:

  1. how reliable is it for the namespace file to exist (I assume this is not going to change anytime in the near future)
  2. would any user run this "out of cluster"

Copy link
Collaborator

Choose a reason for hiding this comment

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

  1. I don't expect this to change. It would probably be considered an API break
  2. It's possible someone may want to run this out of cluster, but we can wait for a feature request to add the option back.

Copy link
Contributor Author

@andrewsykim andrewsykim Apr 1, 2019

Choose a reason for hiding this comment

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

I'm okay with the current PR merging as is, but having the --leader-election-namespace flag as optional in all the sidecars. Setting --leader-election-namespace calls the namespace override using WithNamespace. Otherwise, default to cluster namespace. Thoughts?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think it's fine to maintain backwards compatibility. If the default doesn't work, then the user needs to explicitly specify something.

@msau42
Copy link
Collaborator

msau42 commented Apr 1, 2019

/lgtm
/approve

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Apr 1, 2019
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andrewsykim, msau42

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants