Add RFC: kp dashboard #548
Conversation
aemengo
requested review from
tylerphelan,
djoyahoy,
sukhil-suresh,
elenorebastian,
tomkennedy513,
sampeinado,
mgibson1121 and
matthewmcnew
|
Have you considered creating an Octant plugin? We recently created a plugin for Knative. |
+1, I actually drafted this comment when I saw this! Octant plugins are pretty easy to build (even I can do it!) and written in Go which might help the community contribute to it. Possible disadvantages might be tying to Octant's roadmap/feature set, but I don't know how much of a deal breaker that is. |
Signed-off-by: Anthony Emengo <aemengo@vmware.com>
aemengo
force-pushed
the
rfc/kp-dashboard
branch
from
9dc9f8c to
6abbca3
Compare
|
We have investigated an Octant plugin as well. So, this would likely be in addition to an octant plugin. |
|
|
||
| ## Actions to take | ||
|
|
||
| All implementation code would likely reside in the [kpack-cli](https://github.com/vmware-tanzu/kpack-cli) repository. The step to take would be to implement a `kp dashboard` command that launches a full-screen variant of the terminal interaction shown in the mockup above. |
There was a problem hiding this comment.
Really like the idea of this living in the kp CLI rather than a separate binary. Bit of a nitpick, but I'd prefer it called kp debug to indicate the use case it is trying to solve. Name can be workshopped separate from this RFC.
|
|
||
| ## Risks | ||
|
|
||
| 1. A risk lies in introducing disharmony into the user experience of the kpack-cli. An end user might wonder: "Are there are multiple ways to do the same thing? What is the best way to do X?". |
There was a problem hiding this comment.
I think users are always looking for a suggested way to solve a problem or complete a task as a lot of the kpack resources involve new concepts (stacks, buildpacks, stores, builders, etc...). To me it makes sense to provide some help to our users even if they could make do traversing the different resources individually.
|
I'm a huge fan of the "Details" panel. @aemengo I may have expressed this point to you when we initially spoke about this RFC. The Details panel is currently organized based on whether the object is namespace or cluster scoped. I think that if it were instead organized based on the logical mapping of utilized resources (i.e. image -> builder -> clusterstore (buildpacks)/clusterstack) it would more effectively address the problem of following the chain of each individual resource by inspecting objects you call out in the Problems section. |
|
@imjasonh and @scothis you make a good point that this proposal takes the CLI a step closer to a web app GUI, but I think its actually accomplishing something quite different. A full web app would allow the user to accomplish tasks, the same ones the CLI enables, just in a more visual way. As proposed, I believe this RFC is a new piece of functionality, a "map" display for the user to pull up and see where they want to go next. It doesn't enable the full debugging workflow. It's just one single step in that workflow, a wayfinding step, that would allow you to then identify the kpack resource that you want to troubleshoot. One of the weaknesses of the kp cli today is that it doesn't show connections between resources very well, even though the heirarchy / "flow" of resources (stack+store => builder => image => build) is one of the foundational concepts of kpack. For these reasons, I would be in favor of this RFC being a part of the kp CLI. |
|
Last month we got some feedback from a kpack user asking if there is any way to see the association between a ClusterBuilder and an image using the 'kp' CLI. This one more piece of evidence that suggests this kind of high level "map" view would be helpful as part of the CLI experience! |
|
@aemengo / @sampeinado ⛏️ digging this one back up. It sounds like the idea of a "map" has been brought up a few times. What do you all envision it looking like? Given this is a GUI, got any mock ups? |
Readable