actually I think there is a precedence for this in PrepareForCreate function of podStrategy which sets:

	pod := obj.(*api.Pod)
	pod.Status = api.PodStatus{
		Phase:    api.PodPending,
		QOSClass: qos.GetPodQOS(pod),
	}

	podutil.DropDisabledPodFields(pod, nil)

According to the docs, the zero value of List is an empty list that's ready to use. It looks like it gets lazily initialized as elements are added.

@gnufied: The following tests failed, say /retest to rerun all failed tests:

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

<details>

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. I understand the commands that are listed here. </details> <!-- test report -->

@gnufied: The following tests failed, say /retest to rerun all failed tests:

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

<details>

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. I understand the commands that are listed here. </details> <!-- test report -->

@SergeyKanzhelev: Closing this issue.

<details>

In response to this:

/close

please re-open if the bug is still relevant

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. </details>

For the context: https://github.com/kubernetes/kubernetes/issues/28369 https://github.com/kubernetes/kubernetes/issues/37292 https://github.com/kubernetes/kubernetes/issues/29715

Current mechanism, running logrotate as a cron job hourly in the copytruncate mode poses several problems

• copytruncate mode doesn't integrate well with external logging agents
  • line broken in the middle can sometimes make fluentd enter infinite crashloop (hard to reproduce, so no issue for that, but happened several times during high load)
  • logging agent store read offsets, but copytruncate makes these offsets invalid, which may result in losing lines between the old offset and the size of file right before the rotation
• Rotating logs hourly without the ability to reconfigure doesn't scale very well for highly verbose applications

Something should be implemented to replace the current solution, either on the node level or as a DaemonSet.

CC @kubernetes/sig-node @kubernetes/sig-instrumentation

/close

please re-open if the bug is still relevant

@trozet: The following tests failed, say /retest to rerun all failed tests:

Full PR test history. Your PR dashboard.

<details>

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. I understand the commands that are listed here. </details> <!-- test report -->

@liggitt: The following tests failed, say /retest to rerun all failed tests:

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

<details>

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. I understand the commands that are listed here. </details> <!-- test report -->

/assign

@dashpole this assignment happened last year. Do you still want to work on this?

as per the issue - log rotation is implemented in CRI now. And Dockershim is deprecated. Is this still an issue?

KEP: https://github.com/kubernetes/enhancements/issues/2411

update: they don't make sense for the CRI to return, as they're stats based on the device themselves

good idea

added

updated!

Can you confirm if this is still a bug on more recent kubernetes versions?

/remove-lifecycle frozen

@gnufied: The following tests failed, say /retest to rerun all failed tests:

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

<details>

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. I understand the commands that are listed here. </details> <!-- test report -->

This is pretty challenging to clean up, these environment variables are sort of an "API", I think we should probably drop it from the docs, as this script is really not suitable for any sort of production use, it's just still widely used in the project's CI.

https://github.com/kubernetes/kubernetes/blob/master/cluster/README.md (see deprecation notice)

@gnufied: The following tests failed, say /retest to rerun all failed tests:

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

<details>

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. I understand the commands that are listed here. </details> <!-- test report -->

Being mostly on the user side I do feel a lot of frustration with these. I think auto-closing specifically in the case of a ticket/PR being in a "waiting for OP to respond" state is okay but when the issue is accepted as real and there's nothing more to say, then auto-closing them is pretty grumble-inducing. Auto-cloing untriaged tickets/PRs feels like a gray area, can see both sides, and probably should be a special case and a sign that our triage process needs improvement.

cc @skmatti

/assign

@soltysh: The following tests failed, say /retest to rerun all failed tests:

Full PR test history. Your PR dashboard.

<details>

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. I understand the commands that are listed here. </details> <!-- test report -->

/remove-sig node

from a node perspective this is somewhat expected behavior

@liggitt: The following tests failed, say /retest to rerun all failed tests:

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

<details>

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. I understand the commands that are listed here. </details> <!-- test report -->

/remove-lifecycle stale

@gnufied: The following test failed, say /retest to rerun all failed tests:

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

<details>

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. I understand the commands that are listed here. </details> <!-- test report -->

/retest

/retest

Please review the full test history for this PR and help us cut down flakes.

@idvoretskyi I'm experiencing this with Kops on 768319786644, but cluster-api-provider-aws runs on different accounts

I think this is reasonable, most developers are not building the test images anyhow, I'm not sure exactly where we should draw the line for the core images which lots of people are building all the time for development in addition to downstream distros, but for test images mostly built by CI this seems fine without getting too into the weeds.

I think there's a discussion to be had somewhere about what docker version is reasonable to require, along with the buildx issue