Missing events on status config map

[enxebre]

Even though Scale-up: group events (https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/core/scale_up.go#L715) should have been triggered as well for the status configMap as shows the log:

Event(v1.ObjectReference{Kind:"ConfigMap", Namespace:"test", Name:"cluster-autoscaler-status", UID:"6f9ba031-9377-4984-8a91-a8f6ef363f63", APIVersion:"v1", ResourceVersion:"225776", FieldPath:""}): type: 'Normal' reason: 'ScaledUpGroup' Scale-up: group test/e2e-d6645-w-2 size set to 2

I can always only see/receive one single Scale-up: setting (https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/core/scale_up.go#L701) event:

kubectl describe configmap cluster-autoscaler-status

Events:
  Type    Reason         Age   From                Message
  ----    ------         ----  ----                -------
  Normal  ScaledUpGroup  50s   cluster-autoscaler  Scale-up: setting group test/e2e-d6645-w-1 size to 2

Not sure what I'm missing.

[enxebre]

If I revert 6601bf0 I see all the events coming through.

[MaciekPytel]

@vivekbagade Can you take a look?

[vivekbagade]

@MaciekPytel Sure

[vivekbagade]

Hi @enxebre. The PR you mentioned aggregates events so that CA for scalability reason where we don't want to send a lot of similar events which might happen if we have too many unschedulable pods.

We'll fix this by having a different config for the logrecoder. Expect the fix some time next week

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[marwanad]

@vivekbagade any updates on this issue? It seems that since 1.16, scale up failures are also not logged on the configmap properly. Reverting this change seems to make things work as normal though.

/remove-lifecycle rotten

[marwanad]

@vivekbagade @MaciekPytel gentle ping on this issue. It seems that the events are restricted to one per nodegroup.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[elmiko]

/remove-lifecycle rotten

@vivekbagade and @marwanad i am looking into making some progress on this, do you remember what the logrecorder fix referenced earlier was referring to?

We'll fix this by having a different config for the logrecoder.

i have some time to create a patch here, but i'm a little confused about that statement. alternatively we could revert the change. curious to hear any thoughts if folks remember this ;)

[elmiko]

/reopen

[k8s-ci-robot]

@elmiko: Reopened this issue.

In response to this:

/reopen

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.

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR 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 and PRs.

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[elmiko]

/remove-lifecycle rotten

i'm still interested in seeing the ability to get the duplicated messages. i know adding a flag is not an ideal solution, but i would like to propose a solution where the user has the ability to disable de-duplication of messages.

[elmiko]

we talked about this issue at the sig meeting today, i am going to propose a patch with a flag to enable de-duplication of messages.