Move "Namespaces" and "Custom Resource Definitions" under "API Server"

[scothis]

What this PR does / why we need it:

Remove the "API Server" navigation bar group, moving the mutating and validating webhook resources into a new navigation bar group named "Webhooks". APIServices are no longer linked directly from the navigation, but are still present in the resource graph and via deep links.

Which issue(s) this PR fixes

• Fixes Combine API Server related nav items under a single grouping? #1142

Special notes for your reviewer:

Release note:

Remove "API Server" nav group, moving webhook resoruces under "Webhooks" nav group

[bryanl]

I think there is room to discuss organizing the categories we display in the sidebar, but I would like to have some discussion as to what they should be before making a change like this. Is the term API Server what we are looking for here? From a user's point of view, would they think to navigate to this menu?

[wwitzel3]

Thinking about, what is the experience we want, and then working backwards from that, I don't arrive at this.
If I think about, what is the technology we have, and how do we represent that in a menu or UI, then this is what I end up.

When people talk about these resources, there is rarely ever a distinction that Namespaces and CRDs are part of the API Services, that information isn't helping a novice and someone sufficiently advanced will already know it. So maybe, this serves to educate a moderate user, but the navigation isn't for that purpose. We don't need to be "technically right" in our nav, we want to be helpful.

The more I think about this, the more I think I want to do away with API Services and group Webhooks under "Webhooks" and leave Namespaces and CRDs as top level entries.

I do think taking caution so that our navigation is not growing out of control is valid, but I don't think this is the approach to solve that problem.

[mklanjsek]

Are we sure we want to do this? Namespaces are one of key kubernetes resources and hiding them away from the end user doesn't feel like the right thing to do.

As we strive to bring Octant user experience to the next level, we need to think carefully about implications that each change will have on the end user. From an engineer point of view this may make sense, may even be logical, but from the user centric point of view it doesn't make much sense.

[scothis]

#1142 is the issue for the concept behind this PR. I view this PR as a spike of the concept and not something we necessarily have to merge. I should have opened it as a draft, and have updated it accordingly.

[scothis]

The more I think about this, the more I think I want to do away with API Services and group Webhooks under "Webhooks" and leave Namespaces and CRDs as top level entries.

This is probably the best approach. API Services are not something that users should generally interact with. However, as we have seen, when API Services go wrong, the cluster can get wonky. Having a way to discover and diagnose some of these issues is still valuable. Would it be crazy to leave API Services in the resource viewer and direct links, but not include them in the main nav?

[scothis]

Namespaces are one of key kubernetes resources and hiding them away from the end user doesn't feel like the right thing to do.

As we strive to bring Octant user experience to the next level, we need to think carefully about implications that each change will have on the end user. From an engineer point of view this may make sense, may even be logical, but from the user centric point of view it doesn't make much sense.

@mklanjsek I agree with your general conclusion, but want to push back a bit on the reasoning. Namespaces certainly are a concept the users will interact with heavily in Kubernetes (they are impossible to avoid), but that doesn't mean that users will need to configure namespaces in the cluster. Likewise, creating and interacting with custom resources will be common, but adding or configuration new CRDs in a cluster is not common for most users. While it certainly depends on the context and purpose of the cluster, most cluster scoped resources are not intended to be managed by a typical developer within a cluster, they are more traditionally managed by the cluster operator.

[scothis]

I took anther stab at this based on the comment from @wwitzel3

• mutating and validating webhooks are now under a "Webhooks" navigation item
• APIServices are no longer linked from the navigation, but are still mounted in the URL hierarchy and linked in the resource viewer.