Inspektor Gadget UX ideas

[peterbom]

Continuing from this PR thread...

One slight drawback of our current design is that the tree-view/command interface doesn't quite capture the state of the various resources deployed to the cluster. For example, users are able to execute gadget commands even if Inspektor Gadget is not deployed to their cluster (and they will get errors if that happens).

There are a few alternative approaches to mitigate this:

1. Add further checks when running commands, and output a friendly error message explaining what the user would need to do (e.g. deploy IG first).
2. Selectively display commands based on querying the state of the cluster.
3. Use a webview as the primary point of interaction with IG for a cluster, selectively disabling commands that are not valid.

Doing (1) would have the least impact on the existing UX and be straightforward in the short term. One concern with it is that as the number of commands grows, users are presented with more and more options that may not be applicable to the state of their cluster. In an ideal world, only commands which make sense should be displayed to the users. For example, it'd be preferable if only 'deploy' were available in the case where IG is not deployed.

This drawback could be addressed by (2), but it'd require running background queries to poll all the clusters in the explorer view, which is a performance trade-off we've been deliberately avoided making in the past. It would also require extensive performance testing for additional commands.

The idea of (3) is, you'd have a single 'Inspektor Gadget' command for the cluster, which would launch a webview containing appropriate commands for the state of the cluster. There are possible accessibility concerns here, which will need a bit more investigation. But it does address the issues with (1) and (2), and we're already using one for displaying output, and for a bunch of other commands, so it's not really breaking new ground.

The webview could present unavailable commands as disabled (thanks for the idea, @blanquicet) so users can see what capabilities are available, but only commands that are valid for the state of the cluster would be enabled.

Some possible features of a webview presentation might include (hoping for further discussion here):

• Filtering (e.g. nodes, namespaces)
• Dynamic output (that's periodically refreshed, as in the 'top' commands)
• Keeping track of 'trace' resources, that might be long running and persist even if you close and re-open the webview (note from @blanquicet that this would involve yaml-deployment of traces rather than using the CLI, but that might actually fit quite well with the extension).

Please share any thoughts, @Tatsinnit, @rzhang628, @blanquicet, @mauriciovasquezbernal!

[Tatsinnit]

Thank you for this discussion:

All 3 actions sounds like a great ideas, I would think if we go from 1 and 3 as a progression, we can discuss point 2 with more detail. I really like Point 1 and 3 leads to interactive approach as a user story.

Note: phase-0 which we have already if for the folks who know Inskeptor Gadget, as Phase 1 (least impact) and then phase 2 (more interactive)

• ☕ Phase 1 - We can put check in place for gadget deployment exist against the cluster if so then execute the command otherwise don't and present user with message for using deploy gadget opening.

• ☕ Phase 2 - (which is option 3) - using some form of input and decide on the Inpektor Gadget input as build up experience. I feel the way, it's more guided - can give us interactivity, at this point we could use the kuberntes extensions feature parity for live upload of logs.

Some Implementation Level Detail

• Important - This will will actually be more enabling to answer few open ended questions like - shall we use:
  • Webviews approach
    • They are Accessible: https://code.visualstudio.com/api/extension-guides/webview#accessibility
    • A very cryptic guideline here, so from this we can understand better with this excercise: https://code.visualstudio.com/api/ux-guidelines/webviews
  • VsCode multistep wizard:
    * Docs here: https://code.visualstudio.com/api/ux-guidelines/quick-picks
    * Sample: https://code.visualstudio.com/api/ux-guidelines/quick-picks#multiple-steps

Thanks heaps, I am up for whatever approach we chose to do first, ❤️

[blanquicet]

Yep, I like the plan: Work on phase 1 to already provide a better UX, and in the meanwhile we work on phase 2.

[peterbom]

Playing around with the webview idea, I was thinking of something like this. At the moment it just picks up existing traces and displays their output (not properly sorted yet), but there's plenty of scope for improvement without too much difficulty.

[Tatsinnit]

This is neat, PR it up, we can discuss more there. 🚢

[peterbom]

@blanquicet: I recently came back to this and got it into a more presentable state, hoping we might be able to use it.

However...looking at some changes (PR 1291 and PR 1396) to the Inspektor Gadget repo earlier this year, I see the mechanism for communicating with the gadget pods has changed. The experimental code in my branch uses the old-style approach of creating trace resources and execing to gadgettracermanager but the IG client has apparently been changed to use GRPC and no longer use CRs. Interestingly the original approach still seems to work with the latest version (0.19.0), but I guess that's likely to change?

I now see the gadget kubectl plugin supports an -o json argument. Has that been there all along? I assume the recommended approach would be to invoke the gadget kubectl plugin using that, and completely avoid connecting to the gadget pods directly. That way we wouldn't be broken by any back-end changes. Does that sound right?

[blanquicet]

However...looking at some changes (inspektor-gadget/inspektor-gadget#1281 and inspektor-gadget/inspektor-gadget#1396) to the Inspektor Gadget repo earlier this year, I see the mechanism for communicating with the gadget pods has changed. The experimental code in my branch uses the old-style approach of creating trace resources and execing to gadgettracermanager but the IG client has apparently been changed to use GRPC and no longer use CRs. Interestingly the original approach still seems to work with the latest version (0.19.0), but I guess that's likely to change?

Please consider that our goal is to create an API, and for that we are considering gRPC or a golang library, but it might change.

I now see the gadget kubectl plugin supports an -o json argument. Has that been there all along?

Yep, it has been always there. It is just that your initial PoC was showing the IG output as it is, so the columns output was perfect in that case, and that's why I never suggested to use the JSON one. However, if you are considering parsing the IG output to then render it into a specific UI, the JSON output is indeed the way to go.

I assume the recommended approach would be to invoke the gadget kubectl plugin using that, and completely avoid connecting to the gadget pods directly. That way we wouldn't be broken by any back-end changes. Does that sound right?

Exactly. We definitely suggest you to pass through the kubectl gadget plugin until we release a stable API. In that way, you will never be affected by the changes while reaching such a stable stage.

[peterbom]

Good to know! For our purposes we can probably continue using the JSON output from the plugin even after the API is stable, but really useful to know that's the direction you're heading. Thank you for helping me course-correct!