Update Condition guidance - Let's make progress please!

[Davanum Srinivas]

Clayton, Jordan, TimH, Others!

Not sure if we will get a chance to talk about it in sig-arch call, So lining this up for async to make progress:

https://github.com/kubernetes/community/pull/4521 

Can you please look at the latest (comment from 28 days ago) from Evan and see if we can figure out some consensus?

Thanks,

Dims

--

Davanum Srinivas :: https://twitter.com/dims

[David Eads]

I don't know that it's obvious that consensus exists.  Conditions are currently a flexible status reporting mechanism with a consistent schema for inspection.  Trying to constrain that flexibility with opinionated recommendations that even this group doesn't entirely agree upon suggests that the flexibility is useful and exercised.  It also suggests that the constraints the KEP proposes work against the discovered utility of conditions as a concept.

As a group, I think we should be ok with the idea that consensus may not be found.  Regarding the particulars of the last comment:

1. Polarity recommendations are inherently opinionated.  I don't think that one size fits all and I would recommend against creating an opinionated recommendation guide in this instance.
2. Recommending conditions as high level status.  My read of the PR comments suggests there isn't uniform agreement that this is a goal.  However, we do like being able to combine .status.conditions from multiple sources is useful.  A recommendation to use domain specifiers outside of "primary" ownership could be helpful.
3. A library to help with this. The request here is a little too vague.  Enforcing the semantics of the KEP in question seems too opinionated.  Simply providing generic Find, Add, Remove probably doesn't need a KEP.  If more than that is needed, a separate write up makes sense, but I wouldn't expect discussion about it in this change.

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

[James Peach]

On Thursday, June 18, 2020 at 10:31:20 PM UTC+10, David Eads wrote:

I don't know that it's obvious that consensus exists.  Conditions are currently a flexible status reporting mechanism with a consistent schema for inspection.  Trying to constrain that flexibility with opinionated recommendations that even this group doesn't entirely agree upon suggests that the flexibility is useful and exercised.  It also suggests that the constraints the KEP proposes work against the discovered utility of conditions as a concept.

As a group, I think we should be ok with the idea that consensus may not be found.  Regarding the particulars of the last comment:

1. Polarity recommendations are inherently opinionated.  I don't think that one size fits all and I would recommend against creating an opinionated recommendation guide in this instance.
2. Recommending conditions as high level status.  My read of the PR comments suggests there isn't uniform agreement that this is a goal.  However, we do like being able to combine .status.conditions from multiple sources is useful.  A recommendation to use domain specifiers outside of "primary" ownership could be helpful.
3. A library to help with this. The request here is a little too vague.  Enforcing the semantics of the KEP in question seems too opinionated.  Simply providing generic Find, Add, Remove probably doesn't need a KEP.  If more than that is needed, a separate write up makes sense, but I wouldn't expect discussion about it in this change.

There is https://github.com/kubernetes-sigs/cli-utils/tree/master/pkg/kstatus

 

[Nick Young]

This hasn't moved for a while, and I'm kind of stuck waiting, so here are some thoughts. Sorry this turned out longer than I hoped.

The tl;dr is that if https://github.com/kubernetes/community/pull/4521 isn't going to merge, then *something* needs to be done to bring the api conventions in line with actual practice, so that people adding new Conditions to the world can be confident they're useful.

Without recommendations around polarity and the associated behavior, the api conventions around Conditions are much less useful, and don't reflect the current state of the world. The fact is, some projects are already using positive polarity. All we have at the moment is confusion because the conventions doc doesn't reflect what's happening.

For example:
In the current conventions doc, it's recommended that that conditions indicate state in the `abnormal-true` polarity. At the same time, the conditions document says that the absence of a condition should be treated the same as `Unknown` - meaning "this condition *may* exist."

However, for abnormal-true polarity Conditions, in practice, there's not much difference between `Unknown` and `False`, because if anything is going to take an action based on the state of the condition, it's only going to be on the `True` state. The difference between "there's no error" and "I don't know if there's an error" is less relevant when you only care when there's *definitely* an error.

This means that it's kind of implied by the current conventions document that it's okay for conditions to appear when they are `True`, and disappear otherwise. This is how I *assumed* Conditions worked until pretty recently, and it's not really addressed by the API conventions doc.

For positive conditions, though, they *must* always be present, since the distinction between `Unknown` and `False` is relevant (and is usually analogous to the distinction between `hasn't failed or succeeded yet` and `definitely failed`.

What do I want here?

As the owner of a CRD that I'm trying to add Conditions to, what I need to know is:

- what's the expected lifecycle of Conditions? Should a relevant Condition be added as `Unknown` by a relevant controller as soon as it first sees the object? And then updated between the states?
- If I do decide to implement positive conditions, how do I signal that to naive consumers of my CRD?

If there's not going to be consensus about the recommended polarity, that's fine, but in the absence, since some people are using positive-polarity conditions, there *should* be a recommended way to signal that a particular condition is a positive one.

Ways that I've seen suggested to handle this situation, given lack of consensus are:
- add an optional, but recommended field to the upstream condition that indicates the polarity. `polarity`, `isProblem`, or whatever name, absence indicates `abnormal-true` polarity, but you can set it to indicate `normal-true` (positive) polarity. The advantage of this approach is that if can be backported to the `Ready` condition and any other outliers, and also it allows for the same containing object to hold conditions with different polarities.
- Add an apigroup level mechanism (by convention) to determine the polarity of conditions for objects under that apigroup. I'm thinking here of a package-level constant or method that tells you how the Conditions registered under that package would behave. This does not allow easy coordination of conditions on a single containing object, though.

Especially for CRDs, Conditions are becoming the place where the rubber meets the road in terms of actually exposing state to the users of an object. We, as a project, really need a consistent story for how they work to enable people to build things on top of them.

I acknowledge that adding actual status fields is an option, but the commonality between the structure of Conditions means that it's a good way to extensibly add relevant information without making tooling to consume that information much harder.

--

You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/4b82f00e-ef40-4f6c-9eab-422827d6ec9eo%40googlegroups.com.

[Daniel Smith]

On Tue, Jun 23, 2020 at 6:20 PM Nick Young <ino...@gmail.com> wrote:

This hasn't moved for a while, and I'm kind of stuck waiting, so here are some thoughts. Sorry this turned out longer than I hoped.

The tl;dr is that if https://github.com/kubernetes/community/pull/4521 isn't going to merge, then *something* needs to be done to bring the api conventions in line with actual practice, so that people adding new Conditions to the world can be confident they're useful.

Without recommendations around polarity and the associated behavior, the api conventions around Conditions are much less useful, and don't reflect the current state of the world. The fact is, some projects are already using positive polarity. All we have at the moment is confusion because the conventions doc doesn't reflect what's happening.

For example:
In the current conventions doc, it's recommended that that conditions indicate state in the `abnormal-true` polarity. At the same time, the conditions document says that the absence of a condition should be treated the same as `Unknown` - meaning "this condition *may* exist."

However, for abnormal-true polarity Conditions, in practice, there's not much difference between `Unknown` and `False`, because if anything is going to take an action based on the state of the condition, it's only going to be on the `True` state. The difference between "there's no error" and "I don't know if there's an error" is less relevant when you only care when there's *definitely* an error.

This means that it's kind of implied by the current conventions document that it's okay for conditions to appear when they are `True`, and disappear otherwise. This is how I *assumed* Conditions worked until pretty recently, and it's not really addressed by the API conventions doc.

For positive conditions, though, they *must* always be present, since the distinction between `Unknown` and `False` is relevant (and is usually analogous to the distinction between `hasn't failed or succeeded yet` and `definitely failed`.

What do I want here?

As the owner of a CRD that I'm trying to add Conditions to, what I need to know is:

- what's the expected lifecycle of Conditions? Should a relevant Condition be added as `Unknown` by a relevant controller as soon as it first sees the object? And then updated between the states?
- If I do decide to implement positive conditions, how do I signal that to naive consumers of my CRD?

If there's not going to be consensus about the recommended polarity, that's fine, but in the absence, since some people are using positive-polarity conditions, there *should* be a recommended way to signal that a particular condition is a positive one.

Ways that I've seen suggested to handle this situation, given lack of consensus are:
- add an optional, but recommended field to the upstream condition that indicates the polarity. `polarity`, `isProblem`, or whatever name, absence indicates `abnormal-true` polarity, but you can set it to indicate `normal-true` (positive) polarity. The advantage of this approach is that if can be backported to the `Ready` condition and any other outliers, and also it allows for the same containing object to hold conditions with different polarities.
- Add an apigroup level mechanism (by convention) to determine the polarity of conditions for objects under that apigroup. I'm thinking here of a package-level constant or method that tells you how the Conditions registered under that package would behave. This does not allow easy coordination of conditions on a single containing object, though.

I think the first approach directly solves the problem without bells and whistles, and the second one is super complex.

It's slightly silly to (effectively) repeat the schema for each condition in each instance of the condition, but the alternative is some sort of schema registry system which would add a lot of complexity. I don't think it's worth it right now, maybe in v2.

I'd recommend the policy:

* "Polarity is for people" - state the condition in a natural way for humans to understand.

* Absent means we don't know the value of the condition, and we *also* don't know if the setter of the condition is running/active.

* Setters of conditions should set the condition for the objects they're attempting to monitor, even if "Unknown" is the best they can do for a value at the moment. Otherwise, it's difficult to reason about the set of conditions that might suddenly show up on an object and change your opinion about it.

* [optional, up for debate] Add a `polarity: [AbnormalTrue | AbnormalFalse | InformationalOnly]` field. This is optional, we could also require consumers of the condition to understand by convention, as it is today.

* [optional, up for debate] Add a `modifies: [NameOfOtherCondition1, NameOfOtherCondition2]` field. This, along with polarity, allows consumers to aggregate conditions that they don't understand. It's basically the fully general form of pod readiness gates.

(I think (hope?) we can all agree on the first three; so below I'll discuss the last two.)

Downsides:

* Adding fields makes conditions more verbose

* Exposing the dependency graph causes some problems:

  * it either pushes additional work onto clients

  * or we need a condition aggregating controller

  * Objects will appear inconsistent at first glance (like `[Ready: True], [NetworkAttached: False, polarity: AbnormalFalse, modifies: Ready]` really means "ready: False")

  * We could validate that parent conditions have the value implied by their children, but then we'd lose the input of whatever was setting the parent condition.

  * Clients might ignore the modifier condition. We could solve that by making apiserver (or a mutating webhook) generate a modified judgement field in the parent condition, but clients might ignore that, too.

An alternative is to express the "condition schema" implied by my "polarity/modifies" fields in some other way.

* This adds another moving piece; it'd actually be more work for clients to assemble the information themselves.

* Suppose we implemented this with e.g. a CRD expressing the per-object-type condition relationships and a mutating webhook: then we'd still need to add a "modified judgement" field

* ...or we'd need to fabricate additional conditions ("ModifiedReady"); either way, clients would STILL have to change to get the full value.

* This doesn't solve the problem of clients ignoring things.

I'll add these thoughts to the linked PR, email isn't really the best place for this discussion.

Especially for CRDs, Conditions are becoming the place where the rubber meets the road in terms of actually exposing state to the users of an object. We, as a project, really need a consistent story for how they work to enable people to build things on top of them.

I acknowledge that adding actual status fields is an option, but the commonality between the structure of Conditions means that it's a good way to extensibly add relevant information without making tooling to consume that information much harder.

On Mon, 22 Jun 2020 at 08:24, James Peach <jor...@gmail.com> wrote:

On Thursday, June 18, 2020 at 10:31:20 PM UTC+10, David Eads wrote:

I don't know that it's obvious that consensus exists.  Conditions are currently a flexible status reporting mechanism with a consistent schema for inspection.  Trying to constrain that flexibility with opinionated recommendations that even this group doesn't entirely agree upon suggests that the flexibility is useful and exercised.  It also suggests that the constraints the KEP proposes work against the discovered utility of conditions as a concept.

As a group, I think we should be ok with the idea that consensus may not be found.  Regarding the particulars of the last comment:

1. Polarity recommendations are inherently opinionated.  I don't think that one size fits all and I would recommend against creating an opinionated recommendation guide in this instance.
2. Recommending conditions as high level status.  My read of the PR comments suggests there isn't uniform agreement that this is a goal.  However, we do like being able to combine .status.conditions from multiple sources is useful.  A recommendation to use domain specifiers outside of "primary" ownership could be helpful.
3. A library to help with this. The request here is a little too vague.  Enforcing the semantics of the KEP in question seems too opinionated.  Simply providing generic Find, Add, Remove probably doesn't need a KEP.  If more than that is needed, a separate write up makes sense, but I wouldn't expect discussion about it in this change.

There is https://github.com/kubernetes-sigs/cli-utils/tree/master/pkg/kstatus

 

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/4b82f00e-ef40-4f6c-9eab-422827d6ec9eo%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CA%2Bdr%3DDg8zMo23SDvB-yU2BDJDBGZcx-owh%2BvPOdFYa6whRqX%2BQ%40mail.gmail.com.

[Clayton Coleman]

On Wed, Jun 24, 2020 at 12:56 PM 'Daniel Smith' via kubernetes-sig-architecture <kubernetes-si...@googlegroups.com> wrote:

On Tue, Jun 23, 2020 at 6:20 PM Nick Young <ino...@gmail.com> wrote:

This hasn't moved for a while, and I'm kind of stuck waiting, so here are some thoughts. Sorry this turned out longer than I hoped.

The tl;dr is that if https://github.com/kubernetes/community/pull/4521 isn't going to merge, then *something* needs to be done to bring the api conventions in line with actual practice, so that people adding new Conditions to the world can be confident they're useful.

Without recommendations around polarity and the associated behavior, the api conventions around Conditions are much less useful, and don't reflect the current state of the world. The fact is, some projects are already using positive polarity. All we have at the moment is confusion because the conventions doc doesn't reflect what's happening.

For example:
In the current conventions doc, it's recommended that that conditions indicate state in the `abnormal-true` polarity. At the same time, the conditions document says that the absence of a condition should be treated the same as `Unknown` - meaning "this condition *may* exist."

However, for abnormal-true polarity Conditions, in practice, there's not much difference between `Unknown` and `False`, because if anything is going to take an action based on the state of the condition, it's only going to be on the `True` state. The difference between "there's no error" and "I don't know if there's an error" is less relevant when you only care when there's *definitely* an error.

This means that it's kind of implied by the current conventions document that it's okay for conditions to appear when they are `True`, and disappear otherwise. This is how I *assumed* Conditions worked until pretty recently, and it's not really addressed by the API conventions doc.

For positive conditions, though, they *must* always be present, since the distinction between `Unknown` and `False` is relevant (and is usually analogous to the distinction between `hasn't failed or succeeded yet` and `definitely failed`.

What do I want here?

As the owner of a CRD that I'm trying to add Conditions to, what I need to know is:

- what's the expected lifecycle of Conditions? Should a relevant Condition be added as `Unknown` by a relevant controller as soon as it first sees the object? And then updated between the states?
- If I do decide to implement positive conditions, how do I signal that to naive consumers of my CRD?

If there's not going to be consensus about the recommended polarity, that's fine, but in the absence, since some people are using positive-polarity conditions, there *should* be a recommended way to signal that a particular condition is a positive one.

Ways that I've seen suggested to handle this situation, given lack of consensus are:
- add an optional, but recommended field to the upstream condition that indicates the polarity. `polarity`, `isProblem`, or whatever name, absence indicates `abnormal-true` polarity, but you can set it to indicate `normal-true` (positive) polarity. The advantage of this approach is that if can be backported to the `Ready` condition and any other outliers, and also it allows for the same containing object to hold conditions with different polarities.
- Add an apigroup level mechanism (by convention) to determine the polarity of conditions for objects under that apigroup. I'm thinking here of a package-level constant or method that tells you how the Conditions registered under that package would behave. This does not allow easy coordination of conditions on a single containing object, though.

I think the first approach directly solves the problem without bells and whistles, and the second one is super complex.

It's slightly silly to (effectively) repeat the schema for each condition in each instance of the condition, but the alternative is some sort of schema registry system which would add a lot of complexity. I don't think it's worth it right now, maybe in v2.

I'd recommend the policy:

* "Polarity is for people" - state the condition in a natural way for humans to understand.

100% agree

 

* Absent means we don't know the value of the condition, and we *also* don't know if the setter of the condition is running/active.

100% agree "client can't assume that the version of kube/controller they are running even knows about that condition"

 

* Setters of conditions should set the condition for the objects they're attempting to monitor, even if "Unknown" is the best they can do for a value at the moment. Otherwise, it's difficult to reason about the set of conditions that might suddenly show up on an object and change your opinion about it.

100% agree

 

* [optional, up for debate] Add a `polarity: [AbnormalTrue | AbnormalFalse | InformationalOnly]` field. This is optional, we could also require consumers of the condition to understand by convention, as it is today.

Meh

 

* [optional, up for debate] Add a `modifies: [NameOfOtherCondition1, NameOfOtherCondition2]` field. This, along with polarity, allows consumers to aggregate conditions that they don't understand. It's basically the fully general form of pod readiness gates.

Meh

 

(I think (hope?) we can all agree on the first three; so below I'll discuss the last two.)

You have my unqualified agreement to first three.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAB_J3baPin4O75vfiSYh7NpJQ9AFGmV2mvBvi%2B1fiu6dFrnEiw%40mail.gmail.com.

[James Peach]

> On 25 Jun 2020, at 2:56 am, Daniel Smith <dbs...@google.com> wrote:
>
>
>
[snip]

> I think the first approach directly solves the problem without bells and whistles, and the second one is super complex.
>
> It's slightly silly to (effectively) repeat the schema for each condition in each instance of the condition, but the alternative is some sort of schema registry system which would add a lot of complexity. I don't think it's worth it right now, maybe in v2.
>
> I'd recommend the policy:
> * "Polarity is for people" - state the condition in a natural way for humans to understand.

Perhaps I’m stating the obvious, but I think that part of the issue here is that there is an implicit (?) disagreement on this principle. If conditions are solely for humans, then the polarity doesn’t really matter, since it ought to be “obvious” to a native speaker.

If Conditions are truly for humans, then perhaps you could say thay they have arbitrary polarity, but also designate “Ready” as the well-known Condition that contains rolled-up status. “Ready” would have well-defined semantics and would have to be set by some controller that fully understands the semantics of any consituent Conditions.

To lay all my cards on the table - what I really hoped for Conditions was a way to programatically know whether I have successfully updated a resource of arbitrary type. AFAIK there is no other way in the Kubernetes API to genericaly know whether a resource mutation was successful.

J

[Daniel Smith]

On Wed, Jun 24, 2020 at 2:39 PM James Peach <jor...@gmail.com> wrote:

> On 25 Jun 2020, at 2:56 am, Daniel Smith <dbs...@google.com> wrote:
>
>
>
[snip]
> I think the first approach directly solves the problem without bells and whistles, and the second one is super complex.
>
> It's slightly silly to (effectively) repeat the schema for each condition in each instance of the condition, but the alternative is some sort of schema registry system which would add a lot of complexity. I don't think it's worth it right now, maybe in v2.
>
> I'd recommend the policy:
> * "Polarity is for people" - state the condition in a natural way for humans to understand.

Perhaps I’m stating the obvious, but I think that part of the issue here is that there is an implicit (?) disagreement on this principle. If conditions are solely for humans, then the polarity doesn’t really matter, since it ought to be “obvious” to a native speaker.

Well, it's different than what we document at the moment, I think? I think programmatic polarity is needed if you want to aggregate or act on conditions you don't have hardcoded knowledge of, which I do think is something we should think about and try to solve.

It's also a mistake to assume that every not-successful condition makes the whole resource unusable, which sounds like it might be an implicit assumption from some people hoping for universal polarity; that would not be enough to make this programmatic.

 

If Conditions are truly for humans, then perhaps you could say thay they have arbitrary polarity, but also designate “Ready” as the well-known Condition that contains rolled-up status. “Ready” would have well-defined semantics and would have to be set by some controller that fully understands the semantics of any consituent Conditions.

To lay all my cards on the table - what I really hoped for Conditions was a way to programatically know whether I have successfully updated a resource of arbitrary type. AFAIK there is no other way in the Kubernetes API to genericaly know whether a resource mutation was successful.

If you got a success from apiserver, you successfully updated the resource. I suspect you actually want to know if it is activated, enforced, live, etc?

I refer to this concept as "quiescent", and I'd define it as when the actual state matches the desired state, that is, no controller has (or should have) actions pending. The first time an object becomes quiescent after a change is the closest thing to a "ready" or "done" state that Kubernetes has.

If I needed a universal quiescent signal, personally I'd probably make a controller (or mutating webhook on status writes) that read status and existing conditions, and maintained a "quiescent" condition. This information can be gotten from many types, but it's not presented in a standardized way. So, this would give me a plugin-type framework for writing it for all types I know about. We can take guesses for other types. I think doing this would demonstrate that actually many types don't expose enough information. So, solving this problem is a lot bigger than updating condition guidance.

 

J

[Morten Torkildsen]

Programmatically aggregating all conditions on a resource seems difficult as the meaning of each condition would be different, even if we had agreement on the polarity. While some conditions might express the quiescent state of the resource, others might express something completely different and there should be ignored if the goal is to decide whether the resource has become quiescent.

The kstatus (https://github.com/kubernetes-sigs/cli-utils/tree/master/pkg/kstatus) library attempts to provide a way to answer just the question of whether a resource has become quiescent. The library calls this resource status. It contains a number of rules for computing the status for built-in kubernetes types, as well as some recommended conditions for CRDs that the library knows how to interpret. It also recognizes the Ready condition since it is widely used. And for some types, it is actually surprisingly difficult to determine if it has become quiescent.

I agree that conditions should be written to the resource as soon as possible. For the kstatus library, it is useful to be able to know whether a resource use a specific condition (like the Ready condition), even if it is unknown at the time. Combined with ObservedGeneration, it makes it possible for a library to know the set of conditions used by a resource.

It would be possible to wrap the kstatus library in a controller that would write a 'quiescent' condition onto resources. The Application CRD (https://github.com/kubernetes-sigs/application) does something similar, but writes the status for a set of resources to the App CR rather than back to the resources themselves.

MT

[Daniel Smith]

It sounds like you've done all the hard work :)

I'd love to see a kstatus controller and/or mutating webhook that applied a quiescent condition!

--

You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/5434d368-36b6-4569-ba3e-2d76fef2e84dn%40googlegroups.com.

[Evan Anderson]

Thanks for the discussion! I'm working on updating the PR.

There are a few other items that Tim raised that I'm not sure we got agreement on:

1. Are Conditions a valid mechanism for programmatic interactions, and, if so, how do Conditions differ from other types of status fields? Clayton suggests:

Conditions summarize characteristics of object lifecycle that must be generic across multiple types, have a need to convey both state and human message, and can be extended by third parties to add more nuance to existing lifecycle.

 

An object in Kube is a distributed state machine. The state specified to that object should always be fields. Some objects have consistent fields that describe status of the state machine. One of those is observedGeneration. Another one is conditions. Some conditions define generic, multi-object state machine characteristics like Available, Progressing, Ready.

Do we generally agree on this?

2. Tim suggested that programmatic, schematized Conditions were a different item than we have today, and should be totally additive to today. I think I agree that old clients should keep operating, but I'm not sure if we think that applying new concepts like "polarity" or even a "severity" to Conditions would be problematic?

On Wednesday, June 24, 2020 at 3:48:11 PM UTC-7, Daniel Smith wrote:

It sounds like you've done all the hard work :)

I'd love to see a kstatus controller and/or mutating webhook that applied a quiescent condition!

Coming at this from a slightly different point of view -- I'd like to be able to have a UI which can show roughly a tri-state icon: "operation in progress", "quiescent, no serious errors" and "quiescent, not functioning".

It's certainly true that some core resources don't provide sufficient information to determine this (i.e. NetworkPolicy), but my thought on how to approach it would be:

1. Determine which objects already present some similar information: 

   https://github.com/kubernetes/community/pull/4521#discussion_r413100273

2. Define a preferred pattern with an easy mechanism to recognize exceptions

   <I think we're here -- not sure if the end result of this is a KEP?>

 

3. Update existing objects to indicate compliance with the pattern and/or exception status

   <Given the survey in 1, this should be O(week)>

4. For objects which don't have the information, attempt to retrofit in priority order

   This may take a long time, but could be operated like a ratchet: new objects must provide the feedback, and existing objects are upgraded by priority/pain caused.

[Davanum Srinivas]

Tim, Jordan, Clayton,

The PR https://github.com/kubernetes/community/pull/4521 has had no activity since the last update from Evan at the end of July.

Can we please ship it? (or can it! as appropriate)

-- Dims

--

You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/a0cb34ad-de50-4e41-b513-207c2ef8affco%40googlegroups.com.

[Daniel Smith]

I will reread the changes.

This is really hard, so it is getting pushed off because we have an infinite supply of easier things to look at :)

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CANw6fcGV_80ehC3hEn3bdm%2BzhniJfCntTJPdAV0iDSVvCshAUg%40mail.gmail.com.

[Daniel Smith]

Actually if you hide the existing comments and read it, it is pretty digestible.

I left one thought, I'm OK with it otherwise.

[Jordan Liggitt]

I agree with Daniel... that one paragraph was the only one I bumped on. Other than that, I've been happy with it for a while. I'll let Tim chime in with his thoughts on the current state.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAB_J3bYGQrpn28Nadg3TmZeUM7HpHeJLbmfLWr52%3DiK9FdRNvA%40mail.gmail.com.