controller should reconcile the status of PodGroup

[Huang-Wei]

In the latest code, the controller doesn't quite reconcile the status of PodGroup:

• Field status.Scheduled not displayed - fixed by controller should reconcile the status of PodGroup #166

  If a PodGroup is created, we'd expect all status fields to display properly. But for now it's only status.phase.

  $ k get pg pg1 -o yaml 
  ...
  status:
    phase: pending
  

• status.phase not reconciled well

  If a PodGroup doesn't have any associated Pods, it should stay in Pending state. However, it sometimes stays in Running (or other state). We's expect status to be always reconciled.

/kind bug

[Huang-Wei]

@cwdsuzhou @denkensk could you take some time to look into the above 2 issues?

[cwdsuzhou]

I will open a PR to resolve these issues

[cwdsuzhou]

/assign

[cwdsuzhou]

@Huang-Wei

to resolve the 1st issue, we just need remove omitempty of these fields.

about the 2nd issue, I have different opinions. If a group has been Running , it should not go back to Pending again. IMO, we should covert it to Success, Failed or Unknown. If no associated Pods exist, Unknown would be better. For other status, conversion should be similar.

WDYT?

[Huang-Wei]

to resolve the 1st issue, we just need remove omitempty of these fields.

Thanks. Please raise a PR fixing that.

IMO, we should covert it to Success, Failed or Unknown. If no associated Pods exist, Unknown would be better. For other status, conversion should be similar.

It sounds strange to use different states to show whether a PodGroup has been scheduled successfully once or not. Shouldn't the state just stick to its actual state, in a "stateless" manner?

[cwdsuzhou]

to resolve the 1st issue, we just need remove omitempty of these fields.

Thanks. Please raise a PR fixing that.

This does not work. I raise a PR, just add default value to status

[cwdsuzhou]

It sounds strange to use different states to show whether a PodGroup has been scheduled successfully once or not. Shouldn't the state just stick to its actual state, in a "stateless" manner?

Usually, a PG would be related to a job, from the perspective of a job, job status should not be from Running to Pending

[Huang-Wei]

/reopen
as the 2nd item hasn't been resolved.

I think the workflow of how status changes need to rethink a bit. Probably it should be accompanied by informational messages, so that users can know what phase a PodGropu is in, for what reason.

[k8s-ci-robot]

@Huang-Wei: Reopened this issue.

In response to this:

/reopen
as the 2nd item hasn't been resolved.

I think the workflow of how status changes need to rethink a bit. Probably it should be accompanied by informational messages, so that users can know what phase a PodGropu is in, for what reason.

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.

[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-contributor-experience at kubernetes/community.
/lifecycle stale

[k8s-triage-robot]

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-contributor-experience at kubernetes/community.
/lifecycle rotten

[Huang-Wei]

/remove-lifecycle rotten

[JaneLiuL]

/assign I would like to have a try.

[JaneLiuL]

Is it scenario as below is correct? Actually I am really confuse about the PodGroup status. If my understand is correct, I would like to create a doc to describe first. Then I would like to fix the code issue for it :)
@Huang-Wei

Case 1:
Create podGroup minMember=2 , podGroup.status.Phase=pending
PodNum=0 , podGroup.status.Phase=pending
PodNum=2 (Pod all success) , podGroup.status.Phase=pending-->PreScheduling-->Scheduling-->Finished-->Scheduled
PodNum=1 (Pod all success) , podGroup.status.Phase=Scheduled-->Failed
PodNum=0 , podGroup.status.Phase=Failed-->Pending

Case 2:
Create podGroup minMember=2 , podGroup.status.Phase=pending
PodNum=0 , podGroup.status.Phase=pending
PodNum=2 (Pod all fail to start, like imagePullFail) , podGroup.status.Phase=pending--->PreScheduling-->Scheduling-->Failed
PodNum=2 (Pod all success) , podGroup.status.Phase=Failed--->PreScheduling-->Scheduling-->Scheduled
PodNum=0 , podGroup.status.Phase=Scheduled-->Pending

[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