Request for opinions on new workload conditions (Available, Progressing)

[Filip Krepinsky]

Hi,

I would like to discuss adding additional conditions to the workloads as inlined in the KEP [1].  For now I would like to focus on the Available condition, but opinions on the other ones (Progressing, etc) would be helpful as well.

Please let us know if you would welcome these new conditions or if you have any opinions on how they should look. 

I would like to bring up this topic at Monday's sig-apps meeting.

Thank you

Filip

1. KEP: https://github.com/kubernetes/enhancements/tree/master/keps/sig-apps/2804-consolidate-workload-controllers-status

ReplicaSet PR and a discussion: https://github.com/kubernetes/kubernetes/pull/108863

StatefulSet and DaemonSet PRs: https://github.com/kubernetes/kubernetes/pull/111349, https://github.com/kubernetes/kubernetes/pull/111350

[Aldo Culquicondor]

Hi Filip,

I didn't get a chance to review your KEP before it merged.

I'm curious about the rationale for having a `Waiting` and `Running` condition on the Job only.

What is the use case here? Wouldn't it be covered with https://github.com/kubernetes/enhancements/tree/master/keps/sig-apps/2879-ready-pods-job-status?

Aldo

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAEp5oci%3DosJM29zpV9FXWr%2BFAV%2B7uevR2XCgWkS6M058PUDk4Q%40mail.gmail.com.

[Filip Krepinsky]

On Fri, Jul 22, 2022 at 4:14 PM Aldo Culquicondor <aco...@google.com> wrote:

Hi Filip,

I didn't get a chance to review your KEP before it merged.

I'm curious about the rationale for having a `Waiting` and `Running` condition on the Job only. 

What is the use case here? Wouldn't it be covered with https://github.com/kubernetes/enhancements/tree/master/keps/sig-apps/2879-ready-pods-job-status?

To see if the job's pods are struggling to be scheduled / the job is progressing. I see the 2879 KEP could be used for that as well.  

The lifecycle is different to other workloads so we chose these two to be more in line with Job meaning. We need to reconsider the need for these conditions in jobs. Nevertheless, I suppose it would be better for it to be based on Ready as we use this (and Available) in other workloads as well.

[Aldo Culquicondor]

Maybe it would make sense to have a condition equivalent to "Available". But the usecase of checking how many pods already started is already covered by `.status.ready`.

If anything, I don't think we need both `Waiting` and `Running`. You could have `Running`=`false`/`true` instead.

Could you include me in the code reviews when you have them?

Aldo

[Filip Krepinsky]

On Fri, Jul 22, 2022 at 7:20 PM Aldo Culquicondor <aco...@google.com> wrote:

Maybe it would make sense to have a condition equivalent to "Available". But the usecase of checking how many pods already started is already covered by `.status.ready`.

If anything, I don't think we need both `Waiting` and `Running`. You could have `Running`=`false`/`true` instead.

Could you include me in the code reviews when you have them?

I will keep that in mind. Although, I am not sure how fast that will be and I suppose there will probably be additional discussion before that. 

[Clayton Coleman]

I’ll add this to the KEP comments / code reviews along with Aldo, but there is a part of me that would consider what you are describing as “Running” as “Progressing” and “Waiting” is “Progressing = false”.  

Ideally we have very clear cut rules and descriptions on the common conditions that allow people to write consistent client logic across multiple workloads, but ALSO prevent people from accidentally assuming things that aren’t true (which is a problem we have now, even in Deployments).

Ultimately, conditions are there so clients can write correct code that deals with the vagaries of distributed systems, reconciliation, and eventual consistency around execution.  By definition, we’re biting off a hard problem, the KEP definitely has captured lots of that, and we’ll want to give just that extra bit of due diligence to make sure we succeed at that goal.  I’d love to see some worked examples of taking existing client code in Kube / in the ecosystem that *should* leverage these conditions, and show how the new conditions make the code correct, and then review those conditions, as well as docs / writeups around that that people can reference.  An area where I would like to help out if needed, for sure.

[Filip Krepinsky]

Hi all,

I have opened a KEP update [1] wrt the Available condition which we decided not to pursue, but to explore a new condition called Operational instead.

I would very much appreciate any feedback on this.

1. https://github.com/kubernetes/enhancements/pull/3524

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/4fb6b674-e58c-4841-9e14-a671ee6cbe5dn%40googlegroups.com.