Refine conditions column presentation/meaning

[tyrken]

I'm trying out the Application CRD (see https://github.com/kubernetes-sigs/application) which has by default a couple of conditions, i.e.:

    conditions:
    - lastTransitionTime: "2020-11-17T16:55:57Z"
      lastUpdateTime: "2020-11-17T16:55:57Z"
      message: all components ready
      reason: ComponentsReady
      status: "True"
      type: Ready
    - lastTransitionTime: "2020-11-17T16:55:57Z"
      lastUpdateTime: "2020-11-17T16:55:57Z"
      message: No error seen
      reason: NoError
      status: "False"
      type: Error

The latter is unusual but not unheard of, being given as a possibility in https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties.

I was expecting from your documented "wait for all conditions to turn True" in https://github.com/vmware-tanzu/carvel-kapp/blob/develop/docs/apply-waiting.md for this to cause a problem waiting for apply to finish - but luckily kapp 0.34.0 doesn't seem to, so far at least...

It does however show up as a red 1/2 t entry in the Conds column when inspecting/applying/diffing, which is a user-experience annoyance.

I'm not sure if you can rely on any condition of type Error to be "normal-false" as sounds plausible to me, or if there is any annotation/kapp config I can apply to work around this wrinkle...

[cppforlife]

hey @tyrken,

i think you are referring to conditions on Application CR (not CRD). i updated docs to be clear that that rule is for CRD resource itself and not CRs: https://github.com/vmware-tanzu/carvel-kapp/commit/1e48540e9c76ff6f1967cf3029ec5b908843e115.

to add custom waiting behaviour (for CRs for example), you can use wait rules: https://github.com/vmware-tanzu/carvel-kapp/blob/develop/docs/apply-waiting.md#custom-waiting-behaviour (bottom of the page).

It does however show up as a red 1/2 t entry in the Conds column when inspecting/applying/diffing, which is a user-experience annoyance.

yeah that's an interesting thing we dont quite know how to address. conditions arent self descriptive in k8s hence there is no good way to understand programmatically what's "good" or "bad". we will be probably in future rethink conditions column. (do note that conditions column is unrelated to kapp's waiting behaviour -- currently conditions column is only shown to user for information purposes; kapp's waiting behaviour is surfaced in Reconcile state, Rs, and Reconcile info, Ri, columns)

I'm trying out the Application CRD (see https://github.com/kubernetes-sigs/application)

on a related note, im curious about your exploration e.g. how you are using kapp and Application CRD together?

[tyrken]

Thanks for the quick reply @cppforlife, yes I was meaning an Application CR & your explanations make sense. Will proceed as is for now, but look forward to any further developments on the kapp UX behind presenting Conditions. Afraid I can't see any way (if still counting as true-is-good bools) other than heuristics on well-known Types like "Ready" or "Error", maybe with local config to cover fine-tuning. Don't think we need per-instance control via annotations-on-the-resource as it should be global per api kind, surely?

For reference, I found https://dev.to/maelvls/what-the-heck-are-kubernetes-conditions-for-4je7 which gives a useful summary of some conditions in use in projects and the evolution in thinking about them. There's also https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1623-standardize-conditions which at least standardizes condition schemas in 1.19 but doesn't look like it helps us auto-interpret them much.

on a related note, im curious about your exploration e.g. how you are using kapp and Application CRD together?

We're still considering switching from our current PaaS around AWS ECS to K8s, and trying a helm chart to make that transition easy for the other devs. I wanted to add Application CRD as a place to store metadata about team contact info, git repo urls & similar without blowing up the label count on all resources too much. A bit disappointed with the lack of feedback (i.e. success or some view of issues) from "helm deploy", even with "--wait", so thought to try out the much better feedback from using helm-template with kapp. Have to weigh that up against losing the easy rollback we had with the direct helm life-cycle...

[cppforlife]

Afraid I can't see any way (if still counting as true-is-good bools) other than heuristics on well-known Types like "Ready" or "Error"

yeah ive come to that conclusion as well some time ago. kapp table view havent caught up to that.

Don't think we need per-instance control via annotations-on-the-resource as it should be global per api kind, surely?

yeah, that's we ended up adding custom waiting rules to kapp config to be applied to groups of resources instead of individual ones.

thanks for collecting a few useful links btw.

I wanted to add Application CRD as a place to store metadata about team contact info, git repo urls & similar without blowing up the label count on all resources too much.

ive actually recommended to others a solution to the same problem when using kapp. for now since we did not formalize interface for this, ive recommend to create a "well-named" configmap that would contain all this info. it would be deployed along side the application. it may look something like this:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-details
data:
  authors: Developer Dev
  email: [email protected]
  git-repo-url: [email protected]:...

so thought to try out the much better feedback from using helm-template with kapp

if you are curious about our take on configuration building, check out kapp's sister tool: https://get-ytt.io. that could be used instead of helm template.

Have to weigh that up against losing the easy rollback we had with the direct helm life-cycle...

kapp itself doesnt offer functionality of "rolling back" because we do not want to be responsible for storing configuration versions; however, we do, of course, support user providing previous config and giving it to kapp deploy.