Closed vincepri closed 4 years ago
Some controversy over lists of named subobjects vs use of maps
Just getting into CAPI internals so could be off - but - as an interim solution with long term dashboard value --- Maybe for now just putting the right metrics for API calls in place will be a good enough workaround ---
infrastructureRef
will give you provider specific statesstill_awaiting_cloud_controller
curl localhost:9090 | grep cloud_controller
and look at the numbers' If this issue is adequetely resourced, then the status/phase implementation is also great... just wanted to make sure i offered up a lightweight workaround in case this might take a while.
Some drive-by comments (feel free to ping me at evana at vmware.com if I don't notice updates here):
We spent a long time (about 4 weeks) working on Condition design with UX designers and tooling engineers. The end result is specified here, but I'll also give some useful summaries and a link to the library we wrote:
https://knative.dev/docs/serving/spec/knative-api-specification-1.0/#error-signalling
Some of the lessons we learned:
Ready
, for resources which represent an ongoing status, like a DeploymentSucceeded
, for resources which run-to-completion, like a Jobconditions:
- type=Ready
severity=Error
status=True
Severity may be overkill for your needs; we found some cases where it was helpful to be able to pass back information in conditions that didn't indicate an error.
Library implementing consistent ("True = good") polarity, condition aggregation to common top-level: https://godoc.org/github.com/knative/pkg/apis#ConditionSet.Manage
Thank you so much @evankanderson for sharing your experience with conditions! After v1alpha3 is wrapped up, we'll start working on a proposal, the context you provided is going to be super helpful.
/milestone v0.3.x
/assign @fabriziopandini /lifecycle active /area api
As per April 27th 2020 community guidelines, this project follows the process outlined in https://github.com/kubernetes-sigs/cluster-api/blob/master/CONTRIBUTING.md#proposal-process-caep for large features or changes.
Following those guidelines, I'll go ahead and close this issue for now and defer to contributors interested in pushing the proposal forward to open a collaborative document proposal instead, and follow the process as described.
/close
@vincepri: Closing this issue.
@vincepri @ncdc This is linked in the roadmap under "Improved status conditions" https://github.com/kubernetes-sigs/cluster-api/blob/master/docs/book/src/roadmap.md
Based on https://github.com/kubernetes-sigs/cluster-api/issues/1658#issuecomment-620118757 is there a doc related to this? if so is there a place where I can find the link to that doc? I'd expect this ticket to be that place so the roadmap does not lead us to a dead end.
My intention was to add a relevant ref https://github.com/kubernetes/enhancements/pull/1624 to this topic.
new tracking issue for the CAEP is https://github.com/kubernetes-sigs/cluster-api/issues/3005 @enxebre the Kuberenetes KEP is already in the radar
Opening this issue as a placeholder, to be filled as time goes by. We know that the current model has gaps in terms of
Status.Phase
field, its use and shortcomings. We'll be tracking progress towards a proposal and better model within this issue. Feel free to add more information, comments, concerns./kind proposal /milestone Next /priority important-longterm /assign @timothysc