K9s: Sticky filtering is requiring much more efforts to move around than before

[dimm0]

Is your feature request related to a problem? Please describe.
In the previous version to see the pods running on a node I was doing:

:no
/some_node_substring<Enter>
<Enter>

Seeing the pods

Now to do the same I need to do (the shortest path):

:no
/\ (clear the previous filter)
<type the node substring><Enter>
<Enter>
/\<Enter> (clear the previous filter for node)
0 (choose all namespaces)

Finally see the pods. It's twice more work to do that

Describe the solution you'd like
I'd like to be able to disable the sticky filters (which don't make any sense to me, since nodes filter never applies to pods filter etc), and also switch to all namespaces on Node view

Describe alternatives you've considered
Let me come back to previous version... Can't figure that in brew :(

[paivagustavo]

Thanks for your report @dimm0, I do agree with you that in most cases filters should be cleared when switching between resources.

To add another example, today I was filtering by the name of a pod with /name-of-pod and pressed enter to see the containers, but nothing appeared because of filter :(

Maybe we should think a way to make this an option, something in the lines of:

• /some-name is not sticky
• /sticky:some-name is sticky

I think this should be revisited very soon. Could you give us your opinion @derailed ?

I guess we could get to a solution that works for both this case as well for the fuzzy-search, like /fz:some-name, and other filter modifiers in the future.

[derailed]

@dimm0 @paivagustavo Thank you both for the feedback! Rats!! I see your points, tho you can use esc to clear the sticky filter and don't have to clear it manually (so one extra stroke). You are right filtering on nodes and enter to see pods on selected nodes provides 0 value ;( just like Gustavo's points out between pods to containers. I was thinking sticky filters would allow to nav at the application level which made good sense to me ie show me all pods for a given label, see deployments, see services across that label with minimal effort. Here is what I think we could do ie clear the filter during user navigation ie the natural flow for instance dp -> pod -> container. ie navigating the relationships clears the filter. However if the user types in a command directly then the filter sticks ie :dp + filter, :svc, :cm would remain filtered. Would that fly, or would it still be a dud?

@dimm0 me think brew switch k9s 0.8.X would do that trick for your revert strategy ;(
Sorry for the confusion+hassle!

[dimm0]

In some views esc exits the view to previous one, rather than clearing the filter
I never needed the sticky filter feature, although I use k9s daily now. It's too confusing to keep it in mind I think..

Let's say I filtered pods by name, checked the pod yaml, and then need to do something else, like list all nodes.. I need to clear the filter first, I can't just switch to nodes view, although it's obvious that the filter doesn't make sense anymore for nodes

[dimm0]

(⎈ |nautilus:ucsd-haosulab)➜  ~ brew switch k9s 0.8.6
Error: k9s does not have a version "0.8.6" in the Cellar.
k9s installed versions: 0.9.1

[dimm0]

Same problem with sticky namespace for nodes, it was convenient it was showing all namespaces on a node before

[derailed]

@dimm0 - K let's see if other folks pipe in on this. If so we can axe the feature and revisit once we've got a chance to noodle on this some more.

# Hum... How about this?
brew install [email protected] 

[dimm0]

https://stackoverflow.com/questions/3987683/homebrew-install-specific-version-of-formula

All ways are super complicated. I'm not suffering from k9s that much yet :)

[ncsibra]

I see the points when the filtering doesn't make sense, but unlike @dimm0 I'm using this feature 80% of the time since coming out, so for me, it's pretty useful and does not feel like a burden to press esc sometimes(not bumped into a case when switching out from the view instead of clearing the filter, but that's a fair point).

@derailed I don't like your suggestion, kubernetes is too complex, you can't think all of the edge cases in the navigation flow.
I'm following/using your project for a while and I have seen multiple issues asking for an option to make a feature optional/configurable after it was released, like this one.
I think when you develop something for developers/devops you shouldn't try to make predictions(like navigation flow), make features configurable instead and let them decide how they're using it.

I like @paivagustavo idea, it's simple, similar for already known patterns from other programs, like sed/vim command(s/.../..../g), but if you choose this, please, don't use whole words(sticky:something), keep them as short as possible(s:something).

Other option to use different shortcuts for the different searches, e.g. / for regex filter, ? for sticky filter, something like forward/backward search in less or other similar programs, but this could be complicated to remember for several options(regex, fuzzy, label, sticky etc search).

[derailed]

@dimm0 Sticky filtering was removed in 0.9.3. I think we've missed the forest for the trees with this feature. Sorry for the headache. This is on me ;(

I think this is not actually a view filtering feature but a much larger feature that will be tackled in future releases. I'll keep this issue open until we have a change to make it a reality as I do believe this is indeed a valuable feature but not in its current incarnation.

[dimm0]

Glad to see the filter went away, but namespace is still sticky when looking at node pods

[paivagustavo]

Hey folks,

I invite everyone that are interested on the sticky filters to see my proposed solution to this in the PR #419.

cc @ncsibra since you're one of the users of the sticky filters :)

[derailed]

@paivagustavo I think we are tackling this the wrong way.

In my mind Norbert issue boils down to having the ability to navigate an app across its various resources. ie given a label app=fred, have the ability to see the related resources ie dp, svc, etc.... K8s already give us a sticky filter when navigating a managing resource to its dependents. ie dp->pods->containers->logs or svc->pods->containers->logs. The issue right now is we need to somehow group all these top level resources into a manageable bundles (ie the original issue). I feel that with the current PR, one will be constantly toggling stickiness once the filter yields no resources ie pod->container, node->pod, etc... as it does not respect the k8s natural label selector

@ncsibra Don't get me wrong here I am not guessing user flow here. The flow is already pre-determined by K8s given the resource type. ie sticking a filter for deployments app=blee is not the same as listing all pods with app=blee if the deployment is labeled app=blee but specifies a pod selector as app=fred. This yields the wrong expectations 100% of the time!

This is exactly where we went wrong with the original impl and exactly what's wrong with this PR imho. The sticky label really only is accurate for seemingly not related top level resources and totally irrelevant (read DUD!) once a user navigates to managed resources!!

In my mind's eye this goes a bit deeper than a filter. K8s couples resources via label or label expressions and I think K9s should reflect that. ie I want an ability to describe my applications given a set of labels and have a view that allows me to find/navigate across these affiliated resources via the labels but also via static analysis of the resources manifest. So something like kubectl get all -lapp=fred but on steroid. I think what's really needed here is a crosscut view. The view would afford for navigating across dependent resources ie gives the user the ability to view the cluster as a collection of applications thus allow the user to crosscut by application. I think this feature feels like the namespace feature but in this case the dimension is the crosscut.

Here is what I envision this feature (yes I know a bit heavier than this PR....). I think K9s can do a better job to elevate the user perspective of the cluster by breaking it down into higher level concept vs remaining in resource muck as with kubectl. We need a way to easily specify a crosscut view that deal with a concept (like a namespace) and affords the user to discover/navigate thru the various resources that make up crosscut.

For example...

Say we have deployed a postgres on our cluster. The user wishes to see all resources using the following label expression app=postgres,tier=backend. (These crosscuts could be dynamic or persisted and shared across cluster owners!)

The crosscut view would display:

1. Related Deployment|StatefulSet|DaemonSets|CronJob/Job, etc...
2. Related pods associated with managing resources above
   
   
   
   1. Show service accounts
   
   
   2. Show network/security policies
   
   
   3. Volumes/PVs/PVCs
   
   
   4. Others ie disruption budgets, affinities
   
   
3. Related containers associated with pods above
   
   
   
   1. Show secrets
   
   
   2. Show configmaps
   
   
   3. Others...
   
   
4. Related services
5. Related ingresses
6. Etc...

In my mind this is what we should be gunning for! Useful to any cluster explorers and isolate a particular application for root cause analysis.

.... then again if you guys think I need to lay off the pipe that would be fair too ;)

[paivagustavo]

@derailed I totally understand your points and that is for sure a big feature that will bring k9s to another level. I don't think there is any tool or web application that can bring show this kinda of information as of today.

I did think about this a while back but I was think how we could integrated with Helm and other tools like that. Initially I thought about a centralized view with various resources as you suggested (If I understand you correctly) and this could be very well customized for not only Helm but for day-to-day use and others tools as well.

That being said, I think we should bring a quick solution to the existing user flows of k9s. And when this big shiny feature gets designed, implemented and released, I'm sure people would stop using the "sticky filter" solution.

[ncsibra]

@derailed Sounds really good, but as you said, it's much heavier than this PR and it would take much more time to develop and test it.
I agree with @paivagustavo, just do the easiest solution possible for now and remove it later when the crosscut view is done.