feat(nomos): poll status until repositories complete - #2242
Conversation
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Hi @ahmadalguydi. Thanks for your PR. I'm waiting for a GoogleContainerTools member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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. |
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
| if state == nil || state.Error != "" || len(state.repos) == 0 { | ||
| return false | ||
| } | ||
| for _, repo := range state.repos { |
There was a problem hiding this comment.
Thank you for working on this! From what I read, allSynced returns true as soon as the repository is SYNCED (applied). However, it does not verify if the actual underlying resources have finished reconciling (e.g., reaching status Current in the Resource Group). If a deployment is successfully applied but goes into CrashLoopBackOff, this logic will still consider it "Complete".
Could you clarify if the intent is to wait for Apply completion or full Resource Readiness? If it's readiness, we should also iterate over repo.resources. If it's just apply, we should explicitly document this behavior so automation doesn't falsely assume workloads are ready to serve traffic.
There was a problem hiding this comment.
Thanks — the intended meaning is Config Sync resource reconciliation, not application readiness. A workload can still be unhealthy after its managed resource is applied, so --poll-until=complete must not promise readiness such as avoiding CrashLoopBackOff.
The current PR head (64ff1554) now requires every ResourceGroup entry to be Current in addition to a SYNCED repository, with a regression case for a failed managed resource. The design note now makes that boundary explicit.
Treat poll-until complete as full resource readiness, not only repository apply completion. Keep polling when a reported managed resource is not Current and document the behavior.\n\nAddresses maintainer review on GoogleContainerTools#2006.
|
Followed up on the readiness question in commit The Google CLA bot still requires the account holder to complete the CLA; that external signature step cannot be performed by the agent. |
2 participants
Fixes #2006\n\nAdds
omos status --poll-until=complete for automation that needs to wait until every reachable RootSync and RepoSync reports SYNCED without errors. The command prints immediately, uses an explicit --poll interval when supplied, and defaults to a conservative five-second interval for completion polling. Invalid completion values fail before cluster requests.\n\nThe PR includes the required provisional design document (docs/design-docs/03-poll-until-status.md) and focused tests for complete, pending, errored, and empty states.\n\nValidation: git diff --check passed. Go is not installed in this Windows environment, so the focused Go test and full repository test suite remain for CI.