Revisiting the Roadmap

[karayim]

Roadmap

The existing themes could be reworded to reflect the goal of Octant to be the best tool for developers to understand how applications run on a Kubernetes cluster.

Current Themes

• Working with your Kubernetes workloads
• Answering the question, "why isn't my workload working?"
• Extending Octant to work with any Kubernetes type
• Providing better defaults
• Being a better ecosystem participant

Example
Answering the question, "why isn't my workload working?" -> Provide excellent Kubernetes debugging and troubleshooting

All feedback welcome!

[xtreme-vikram-yadav]

Notes from community meeting:

Providing better defaults:
Help users understand the scope of workloads. Default view in octant about app configuration, deployment.
Show metadata about deployment methods and controllers may be by using labels.
Provide clear ways to understand the workload association with resources within cluster.
Applications view and resource viewer in octant are examples of this.

Being a better ecosystem participants:
Speed and efficiency improvement are part of it. Octant performs well for small to medium cluster but not for large clusters.
Making sure the plugin libraries (including community managed plugins) are working well is a part of it.
We have avoided collecting performance metrics in the past because every cluster is different.

Some themes seems to have overlapping objectives and we may need segregation into their own themes.

[karayim]

Suggestion
Working with your Kubernetes workloads -> Elevate the Kubernetes experience
(essentially moving the experience of working with K8s from one of pure functionality to one that is more meaningful)

[wwitzel3]

I like this a lot.

[wwitzel3]

Thinking about, Extending Octant to work with any Kubernetes type:

This is really about ensuring we can do a few things.

1. out of the box, any type we encounter, we are able to render some default view for it, this default view should be somewhat useful based on the resource definition and metadata / labels.

2. Octant as a platform for building plugins. Octant support both Go and TypeScript plugins which is great, but the next level of this is being able to thing of any resource a "data" and an Octant plugin as views and actions for that data.

3. Extending Octant, for basic read-only data, would ideally take little to no coding. Building a view in Octant would be done in Octant and you could link up data sources, read resource types, and may the data to components as desired. The results of that could be exported and shared easily.

[karayim]

Is it possible to wrap this one up with something like, "Enable plugin authors to provide a great experience specific to their needs." I realize that may ignore point 1 above, but that could fall within "Elevating the Kubernetes experience." Relegating plugins to within an "any type" theme ignores the power and potential of the plugin platform. Or perhaps there are 2 different themes here? In a conversation with @lenriquez, he enumerated the needs of plugin authors and I'll let him chime in here. So maybe there's 1 theme for being able to support any K8s type and another for supporting the plugin platform.

[lenriquez]

Yes! I was thinking on theme like "Provide the best UI platform for developer", we could encapsulate this two points where developers could create the data sources

[lenriquez]

I still have problems to understand "Provide better defaults" it sounds like is "Provide different perspectives to see Kubernetes workload" but I am not completely sure

[davidmirror-ops]

One of the Octant original goals is "to make Kubernetes more accessible by lowering the barriers around learning." and also to answer the question of "why isn't my workload running?".

Nevertheless my recent experience using Octant still falls short on those goals.

1. Providing better defaults is a must, as right now the initial view is a list of resources in the clusters but without any explicit relationship between them:

Due to that, in order to find the root cause of an issue, a user has to know where to search in the K8s object hierarchy. In the example the warning is shown at the StatefulSet and Pod levels but the error is at the PVC/Storage Class level

I'm wondering if "Applications" should be the default view instead of Namespaces Overview. The reason is that "Applications" provides a simple, fast and visual way to determine whether something is wrong with the workloads or not.

2. Resource Viewer is awesome but it shows a different hierarchy depending on the selected object. Example from a Pod:

From that view, i could infer that if i fix an issue in the StatefulSet or the Service, it will help fix the Pod issue (whatever it is) but that's not the case. The Pod spec is part of the StatefulSet declaration and not the opposite.

Same cluster but now from the StatefulSet shows a totally different hierarchy:

3. Regarding the YAML Editor, making it object aware (as also is planned in the original Roadmap) will be really helpful because currently Octant users don't have any indication on which portions of a spec of an already-created object can be edited and which can't.

4. Finally, proper positioning for Octant should be explored. I mean, is it a platform to build developer experiences? In that case, the Plugin lifecycle and ecosystems is one of the main areas to focus on. Is it a debugging/troubleshooting companion tool? In that case, correlating the Last Event to the object status won't be enough as also it will have to capture additional metrics/signals so Devs/SREs can have a better idea on where the root cause of a workload problem could be and also if it's being caused by anomalous metrics like Latency/Error Rate/etc

[wwitzel3]

At it's core, Octant is a platform to build developer experiences on Kubernetes. One of those experiences we would like to enable by default is a debugging and troubleshooting workflow.

[wwitzel3]

@davidmirror-ops referenced this https://learnk8s.io/a/a-visual-guide-on-troubleshooting-kubernetes-deployments/troubleshooting-kubernetes.v2.pdf as steps Octant could do for you ..