This repository was archived by the owner on Apr 20, 2026. It is now read-only.
container ordering: Don't run application container when container status is not available#37
Merged
abhinavdahiya merged 1 commit intorelease-1.22.9-lyft.4from May 5, 2023
Conversation
…atus is not available 1. When all container statuses are nil, we should default to application containers wait untill statuses are available 2. When application container is nil, we should default to application containers waiting state
abhinavdahiya
force-pushed
the
fix_container_wait
branch
from
dd3ed1f to
d65edc5
Compare
Author
|
ptal #compute @tomwans |
abhinavdahiya
changed the title
tomwans
approved these changes
May 5, 2023
abhinavdahiya
changed the base branch from
release-1.22.9-lyft.3
to
release-1.22.9-lyft.4
abhinavdahiya
added a commit
that referenced
this pull request
May 10, 2023
…atus is not available (#37) 1. When all container statuses are nil, we should default to application containers wait untill statuses are available 2. When application container is nil, we should default to application containers waiting state
abhinavdahiya
added a commit
that referenced
this pull request
May 10, 2023
…atus is not available (#38) Backport #37 to 1.16 1. When all container statuses are nil, we should default to application containers wait untill statuses are available 2. When application container is nil, we should default to application containers waiting state <!-- Thanks for sending a pull request! Here are some tips for you: 1. If this is your first time, please read our contributor guidelines: https://git.k8s.io/community/contributors/guide/first-contribution.md#your-first-contribution and developer guide https://git.k8s.io/community/contributors/devel/development.md#development-guide 2. Please label this pull request according to what type of issue you are addressing, especially if this is a release targeted pull request. For reference on required PR/issue labels, read here: https://git.k8s.io/community/contributors/devel/sig-release/release.md#issuepr-kind-label 3. Ensure you have added or ran the appropriate tests for your PR: https://git.k8s.io/community/contributors/devel/sig-testing/testing.md 4. If you want *faster* PR reviews, read how: https://git.k8s.io/community/contributors/guide/pull-requests.md#best-practices-for-faster-reviews 5. If the PR is unfinished, see how to mark it: https://git.k8s.io/community/contributors/guide/pull-requests.md#marking-unfinished-pull-requests --> #### What type of PR is this? <!-- Add one of the following kinds: /kind bug /kind cleanup /kind documentation /kind feature Optionally add one or more of the following kinds if applicable: /kind api-change /kind deprecation /kind failing-test /kind flake /kind regression --> #### What this PR does / why we need it: #### Which issue(s) this PR fixes: <!-- *Automatically closes linked issue when PR is merged. Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`. _If PR is about `failing-tests or flakes`, please post the related issues/tests in a comment and do not use `Fixes`_* --> Fixes # #### Special notes for your reviewer: #### Does this PR introduce a user-facing change? <!-- If no, just write "NONE" in the release-note block below. If yes, a release note is required: Enter your extended release note in the block below. If the PR requires additional action from users switching to the new release, include the string "action required". For more information on release notes see: https://git.k8s.io/community/contributors/guide/release-notes.md --> ```release-note ``` #### Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: <!-- This section can be blank if this pull request does not require a release note. When adding links which point to resources within git repositories, like KEPs or supporting documentation, please reference a specific commit and avoid linking directly to the master branch. This ensures that links reference a specific point in time, rather than a document that may change over time. See here for guidance on getting permanent links to files: https://help.github.com/en/articles/getting-permanent-links-to-files Please use the following format for linking documentation: - [KEP]: <link> - [Usage]: <link> - [Other doc]: <link> --> ```docs ```
abhinavdahiya
added a commit
that referenced
this pull request
Jun 22, 2023
…nt (#40) based on https://lyft.slack.com/archives/C017X524VC7/p1685639606706689?thread_ts=1685481685.730389&cid=C017X524VC7 when there are no sidecars we should allow all containers to start even when there is lack of container status. This fixes a regression introduced in #37 where we would block starting containers until we get container status reported. this triggers KillPod action in 1.16 as no progress can be made. --------- Co-authored-by: Tom Wanielista <tomwans@users.noreply.github.com>
abhinavdahiya
added a commit
that referenced
this pull request
Jun 22, 2023
…nt (#40) based on https://lyft.slack.com/archives/C017X524VC7/p1685639606706689?thread_ts=1685481685.730389&cid=C017X524VC7 when there are no sidecars we should allow all containers to start even when there is lack of container status. This fixes a regression introduced in #37 where we would block starting containers until we get container status reported. this triggers KillPod action in 1.16 as no progress can be made. --------- Co-authored-by: Tom Wanielista <tomwans@users.noreply.github.com>
abhinavdahiya
added a commit
that referenced
this pull request
Jun 22, 2023
…nt (#41) Backport (#40) based on https://lyft.slack.com/archives/C017X524VC7/p1685639606706689?thread_ts=1685481685.730389&cid=C017X524VC7 when there are no sidecars we should allow all containers to start even when there is lack of container status. This fixes a regression introduced in #37 where we would block starting containers until we get container status reported. this triggers KillPod action in 1.16 as no progress can be made. Co-authored-by: Tom Wanielista <tomwans@users.noreply.github.com>
abhinavdahiya
added a commit
that referenced
this pull request
Jun 26, 2023
…atus is not available (#37) 1. When all container statuses are nil, we should default to application containers wait untill statuses are available 2. When application container is nil, we should default to application containers waiting state
abhinavdahiya
added a commit
that referenced
this pull request
Jun 26, 2023
…nt (#40) based on https://lyft.slack.com/archives/C017X524VC7/p1685639606706689?thread_ts=1685481685.730389&cid=C017X524VC7 when there are no sidecars we should allow all containers to start even when there is lack of container status. This fixes a regression introduced in #37 where we would block starting containers until we get container status reported. this triggers KillPod action in 1.16 as no progress can be made. --------- Co-authored-by: Tom Wanielista <tomwans@users.noreply.github.com>
abhinavdahiya
added a commit
that referenced
this pull request
Jun 26, 2023
…atus is not available (#37) 1. When all container statuses are nil, we should default to application containers wait untill statuses are available 2. When application container is nil, we should default to application containers waiting state
abhinavdahiya
added a commit
that referenced
this pull request
Jun 26, 2023
…nt (#40) based on https://lyft.slack.com/archives/C017X524VC7/p1685639606706689?thread_ts=1685481685.730389&cid=C017X524VC7 when there are no sidecars we should allow all containers to start even when there is lack of container status. This fixes a regression introduced in #37 where we would block starting containers until we get container status reported. this triggers KillPod action in 1.16 as no progress can be made. --------- Co-authored-by: Tom Wanielista <tomwans@users.noreply.github.com>
abhinavdahiya
added a commit
that referenced
this pull request
Jul 28, 2023
…atus is not available (#37) 1. When all container statuses are nil, we should default to application containers wait untill statuses are available 2. When application container is nil, we should default to application containers waiting state
abhinavdahiya
added a commit
that referenced
this pull request
Jul 28, 2023
…nt (#40) based on https://lyft.slack.com/archives/C017X524VC7/p1685639606706689?thread_ts=1685481685.730389&cid=C017X524VC7 when there are no sidecars we should allow all containers to start even when there is lack of container status. This fixes a regression introduced in #37 where we would block starting containers until we get container status reported. this triggers KillPod action in 1.16 as no progress can be made. --------- Co-authored-by: Tom Wanielista <tomwans@users.noreply.github.com>
abhinavdahiya
added a commit
that referenced
this pull request
Aug 9, 2023
…atus is not available (#37) 1. When all container statuses are nil, we should default to application containers wait untill statuses are available 2. When application container is nil, we should default to application containers waiting state
abhinavdahiya
added a commit
that referenced
this pull request
Aug 9, 2023
…nt (#40) based on https://lyft.slack.com/archives/C017X524VC7/p1685639606706689?thread_ts=1685481685.730389&cid=C017X524VC7 when there are no sidecars we should allow all containers to start even when there is lack of container status. This fixes a regression introduced in #37 where we would block starting containers until we get container status reported. this triggers KillPod action in 1.16 as no progress can be made. --------- Co-authored-by: Tom Wanielista <tomwans@users.noreply.github.com>
abhinavdahiya
added a commit
that referenced
this pull request
Aug 10, 2023
…atus is not available (#37) 1. When all container statuses are nil, we should default to application containers wait untill statuses are available 2. When application container is nil, we should default to application containers waiting state
abhinavdahiya
added a commit
that referenced
this pull request
Aug 10, 2023
…nt (#40) based on https://lyft.slack.com/archives/C017X524VC7/p1685639606706689?thread_ts=1685481685.730389&cid=C017X524VC7 when there are no sidecars we should allow all containers to start even when there is lack of container status. This fixes a regression introduced in #37 where we would block starting containers until we get container status reported. this triggers KillPod action in 1.16 as no progress can be made. --------- Co-authored-by: Tom Wanielista <tomwans@users.noreply.github.com>
abhinavdahiya
added a commit
that referenced
this pull request
Nov 29, 2023
…atus is not available (#37) 1. When all container statuses are nil, we should default to application containers wait untill statuses are available 2. When application container is nil, we should default to application containers waiting state
abhinavdahiya
added a commit
that referenced
this pull request
Nov 29, 2023
…nt (#40) based on https://lyft.slack.com/archives/C017X524VC7/p1685639606706689?thread_ts=1685481685.730389&cid=C017X524VC7 when there are no sidecars we should allow all containers to start even when there is lack of container status. This fixes a regression introduced in #37 where we would block starting containers until we get container status reported. this triggers KillPod action in 1.16 as no progress can be made. --------- Co-authored-by: Tom Wanielista <tomwans@users.noreply.github.com>
abhinavdahiya
added a commit
that referenced
this pull request
Nov 29, 2023
…atus is not available (#37) 1. When all container statuses are nil, we should default to application containers wait untill statuses are available 2. When application container is nil, we should default to application containers waiting state
abhinavdahiya
added a commit
that referenced
this pull request
Nov 29, 2023
…nt (#40) based on https://lyft.slack.com/archives/C017X524VC7/p1685639606706689?thread_ts=1685481685.730389&cid=C017X524VC7 when there are no sidecars we should allow all containers to start even when there is lack of container status. This fixes a regression introduced in #37 where we would block starting containers until we get container status reported. this triggers KillPod action in 1.16 as no progress can be made. --------- Co-authored-by: Tom Wanielista <tomwans@users.noreply.github.com>
abhinavdahiya
added a commit
that referenced
this pull request
Dec 1, 2023
…atus is not available (#37) 1. When all container statuses are nil, we should default to application containers wait untill statuses are available 2. When application container is nil, we should default to application containers waiting state
abhinavdahiya
added a commit
that referenced
this pull request
Dec 1, 2023
…nt (#40) based on https://lyft.slack.com/archives/C017X524VC7/p1685639606706689?thread_ts=1685481685.730389&cid=C017X524VC7 when there are no sidecars we should allow all containers to start even when there is lack of container status. This fixes a regression introduced in #37 where we would block starting containers until we get container status reported. this triggers KillPod action in 1.16 as no progress can be made. --------- Co-authored-by: Tom Wanielista <tomwans@users.noreply.github.com>
murongl-lyft
pushed a commit
that referenced
this pull request
Mar 8, 2024
…atus is not available (#37) 1. When all container statuses are nil, we should default to application containers wait untill statuses are available 2. When application container is nil, we should default to application containers waiting state
murongl-lyft
pushed a commit
that referenced
this pull request
Mar 8, 2024
…nt (#40) based on https://lyft.slack.com/archives/C017X524VC7/p1685639606706689?thread_ts=1685481685.730389&cid=C017X524VC7 when there are no sidecars we should allow all containers to start even when there is lack of container status. This fixes a regression introduced in #37 where we would block starting containers until we get container status reported. this triggers KillPod action in 1.16 as no progress can be made. --------- Co-authored-by: Tom Wanielista <tomwans@users.noreply.github.com>
murongl-lyft
pushed a commit
that referenced
this pull request
Mar 22, 2024
…atus is not available (#37) 1. When all container statuses are nil, we should default to application containers wait untill statuses are available 2. When application container is nil, we should default to application containers waiting state
murongl-lyft
pushed a commit
that referenced
this pull request
Mar 22, 2024
…nt (#40) based on https://lyft.slack.com/archives/C017X524VC7/p1685639606706689?thread_ts=1685481685.730389&cid=C017X524VC7 when there are no sidecars we should allow all containers to start even when there is lack of container status. This fixes a regression introduced in #37 where we would block starting containers until we get container status reported. this triggers KillPod action in 1.16 as no progress can be made. --------- Co-authored-by: Tom Wanielista <tomwans@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When all container statuses are nil, we should default to application containers wait untill statuses are available
When application container is nil, we should default to application containers waiting state