Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: allow jumping to the owner of the resource #2700

Merged
merged 1 commit into from
May 18, 2024

Conversation

wjiec
Copy link
Contributor

@wjiec wjiec commented May 12, 2024

This PR implements the feature described in #2696 and now allows jumping to the owner view of the currently selected resource with Shift-J.

Copy link
Owner

@derailed derailed left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wjiec Thank you Jayson for taking this on!

My feel is this deviate a bit from the original issue. IMHO the dialog feels a little heavy as the user is really after the controller (if present) and not the collection of owners. In most cases this will work fine as most res will have a single owner. However when we have multiples, my feel is we should just pick the controller and just nav there.

I think what you have here is great. We can float it and adjust based on feedback.

@derailed derailed merged commit f802d39 into derailed:master May 18, 2024
2 of 3 checks passed
@wjiec wjiec deleted the feat/jump-owner branch May 19, 2024 13:23
@wjiec
Copy link
Contributor Author

wjiec commented May 19, 2024

@derailed You're right, I forgot that there can only be one controller = true owner 😅

@gitolicious
Copy link
Contributor

Slight confusion over here as there were two other PRs (#2133, #2640) open for the issue #1747 abouth the same feature, one of which for nearly a year now. @derailed's suggestions were the exact opposite there.

However when we have multiples, my feel is we should just pick the controller and just nav there.

vs.

I think if there are multiple controllers then we should use the same mechanic we currently use for sec/cm aka 'Used By` and show a new view vs a picker to list out controllers fqn/gvr (please see view.reference.go)

Anyways, I am really happy to have the feature available in k9s now.

FYI: the navigation fails for Node owners.

apiVersion: v1
kind: Pod
metadata:
  labels:
    component: kube-scheduler
    tier: control-plane
  name: kube-scheduler-docker-desktop
  namespace: kube-system
  ownerReferences:
  - apiVersion: v1
    controller: true
    kind: Node
    name: docker-desktop
    uid: 012c5363-9d35-474a-a5af-7b0f83a5b1ff
[...]

😡 Watcher failed for v1/nodes -- unable to locate node kube-system/docker-desktop

This was working with my proposed solution. Problem is that a navigation to a namespaced FQN ("kube-system/docker-desktop") is done while the noode owner is namespace-less. I will create another PR to fix that.

@derailed derailed mentioned this pull request Jun 15, 2024
rm-hull added a commit to rm-hull/k9s that referenced this pull request Aug 12, 2024
* 'master' of github.com:derailed/k9s: (169 commits)
  fix: align build image Go version with go.mod (derailed#2812)
  Bump github.com/docker/docker (derailed#2816)
  Bump golangci/golangci-lint-action from 6.0.1 to 6.1.0 (derailed#2813)
  Add comment about Escape keybinding (derailed#2817)
  proper handle OwnerReference for manually created job (derailed#2772)
  [derailed#2773] fix freebsd build failure (derailed#2775)
  install copyright file into correct location (derailed#2780)
  fix status for completed pods in workload view (derailed#2729)
  update deps
  [Maint] Bump grype rev
  K9s/release v0.32.5 (derailed#2740)
  --- (derailed#2707)
  fix view sorting being reset (derailed#2736)
  use policy/v1 instead of policy/v1beta1 (derailed#2732)
  Bump alpine from 3.19.1 to 3.20.0 (derailed#2721)
  fix: jump to namespaceless owner reference (derailed#2718)
  feat: Add plugins for argo-rollouts (derailed#2711)
  Bump golangci/golangci-lint-action from 5.1.0 to 6.0.1 (derailed#2702)
  allow jumping to the owner of the resource (derailed#2700)
  fix: job color based on failures (derailed#2686) (derailed#2698)
  ...
@Tarasovych
Copy link

Thanks, this is an awesome feature!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants