LeaderElectionConfig UserAgent is not honored

[ludydoo]

Problem:

We are seeing two different user-agents for our controller in the kubernetes audit logs.

Expected:

The leader election user-agent should conform to what was specified in the controllerManager configuration.

Actual:

The leader-election user-agent is overriden by the controllerManager.

Details:

725   "userAgent": "stackrox-operator/v0.0.0 (linux/amd64) kubernetes/$Format/leader-election",
893   "userAgent": "rhacs-operator/v3.71.x-17-g7992bde75b development_build (linux/amd64)",

We figured that we were missing the ctrl.Options.LeaderElectionConfig. Trying to set this has no effect. With the following configuration

func getRestConfig() rest.Config {\
   config := ...
   config.UserAgent = "myUserAgent"
}

func main(){
  mgr, err := ctrl.NewManager(getRestConfig(), ctrl.Options{
  Scheme:                  scheme,
  MetricsBindAddress:      metricsAddr,
  Port:                    9443,
  HealthProbeBindAddress:  probeAddr,
  LeaderElection:          true,
  LeaderElectionID:        "1234.stackrox.com",
  LeaderElectionConfig:    getRestConfig(),
  })
}

It seems that the user agent for the leader election client is ignored. Drilling through the code, the function used by the controller to build the leader election user agent is rest.AddUserAgent. That seems to be a misnomer, since it doesn't really "adds a user agent", but only concatenates the default k8s user agent with some suffix. (I would've expected it to rather append the given suffix to a pre-existing user-agent string)

controller-runtime/pkg/leaderelection/leader_election.go

Line 90 in c3c1f05

rest.AddUserAgent(config, "leader-election")

...
rest.AddUserAgent(config, "leader-election")

https://github.com/kubernetes/client-go/blob/4666344cbcd76aba5a198e0fdfc3e7e5051698a9/rest/config.go#L593

func AddUserAgent(config *Config, userAgent string) *Config {
	fullUserAgent := DefaultKubernetesUserAgent() + "/" + userAgent
	config.UserAgent = fullUserAgent
	return config
}

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[troy0820]

This may be resolved as the httpClient for leader election respects the kubeconfig passed into the options for the manager.

Not sure this is what you were saying but this behavior did change and is now in v0.16.0
#2464

[troy0820]

/kind support

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.