-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
✨ [WIP] Add support for kubectl printer columns #1019
Conversation
Adds installed version, resolved version and age printer columns Signed-off-by: kevinrizza <[email protected]>
These seem like reasonable printer columns to me, but we should have some agreement that these make the most sense before committing to them. Leaving this as a WIP pr for now. |
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1019 +/- ##
=======================================
Coverage 78.05% 78.05%
=======================================
Files 18 18
Lines 1253 1253
=======================================
Hits 978 978
Misses 193 193
Partials 82 82
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know if there's a way to set a default value in the printer column if the json path evaluates to null or empty string?
Related: I'm wondering if there's a nice way to get useful information to show up if there are issues resolving or installing a bundle.
I found this kubernetes/enhancements#4602, but obviously not usable yet.
@joelanford I looked around and didn't find anything. Imo we should keep this pr held until we make some improvements to the availability of this metadata. I'm also interested in any other thoughts on other columns we might want to have. |
@@ -183,6 +183,9 @@ type ClusterExtensionStatus struct { | |||
//+kubebuilder:object:root=true | |||
//+kubebuilder:resource:scope=Cluster | |||
//+kubebuilder:subresource:status | |||
//+kubebuilder:printcolumn:name="Installed Version",type=string,JSONPath=`.status.installedBundle.version` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it possible to float up any of the conditions or errors? As a user it would be good to understand: where the CR is in its progression, version state (as above), and some kind of sense of where it stopped (and possibly why?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is possible to write JSON path to do something like "find condition with type "Installed" and tell me it's reason", but that might not be all that helpful because:
- Showing details of every condition type would get pretty verbose
- Only showing details of some condition types could be misleading.
I wonder if, after @bentito's work to wrangle condition updates to reflect reality better, we could do something where right before we send out the status update we pass the conditions into a function that returns $something that somewhat summarizes the state of the conditions. For example:
- Installed=False, Progressing=False => "Failed"
- Installed=False, Progressing=True => "Installing"
- Installed=True, Progressing=False, Healthy=False => "Unhealthy"
- Installed=True, Progressing=False, Healthy=True => "Ready"
- Installed=True, Progressing=True => "Upgrading"
- etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That could be cool. It would just be nice to get some signal without having to inspect the whole status.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been looking into this, and it appears the JSON is limited to being very simple, and you really can't do something that complicated without another field having that value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Error I got when I tried to be a bit more "advanced":
The CustomResourceDefinition "clusterextensions.olm.operatorframework.io" is invalid: spec.additionalPrinterColumns[4].JSONPath: Invalid value: "{range .status.conditions[?(@.type=='Installed' && @.status=='False')]}{range .status.conditions[?(@.type=='Progressing' && @.status=='True')]}{'Installed'}{end}{end}": must be a simple json path starting with .
Where are we on this? Keeping it? Does it need rework? |
/hold This is now out of date, the fields no longer exist. |
Closing if favour of #1421 |
Adds installed version, resolved version and age printer columns
Resolves #1018
Description
Reviewer Checklist