Suggested Changes

[patmessina]

Want to propose some changes, and additions. I will be more than happy to make them myself. Particularly since I have a lot of this done already.

• Change kc to k
• Change kcl to k
• Change n to ns to represent namespaces and use n for nodes
• Large number of alias additions
• Add Completion
• Add help
• Get all resources across namespaces
• Find a resources based on name across all namespaces

Let me know what you want, if anything.

[Dbz]

• Change kc to k
• Change kcl to k

I think adding a k alias is a good idea. I don't want to add unnecessary breaking changes if we can avoid it.

• Change n to ns to represent namespaces and use n for nodes

This is good. It is breaking, but it should have been ns from the start

• Large number of alias additions

Bring them on

• Add Completion

I find that autocompletion is really slow because it has to hit k8s for the answers. Are you proposing some sort of caching? I'm interested in this.

• Add help

Yes

• Get all resources across namespaces

Yes

• Find a resources based on name across all namespaces

Yes

Let me know what you want, if anything.

All the things! Thank you for making this plugin better for everyone.

[patmessina]

I haven't done the completions yet. Ill look into it though, I am not sure how I am going to do that.

I need to go through and make sure what I have isn't conflicting with what is in this plugin. Ill probably will make a pull request next week.

[Dbz]

Awesome; Don't be afraid of making multiple pulls to get the easy stuff in first. I'm happy to help brainstorm the completions with you. Another possibility would be to search through your shell history for auto-completion because I have found myself doing the same thing often.

[patmessina]

Ran across kubectl plugin in zsh. Its auto-complete works fine for me. They have a bunch of aliases as well, but I prefer the ones I have proposed. Not sure why they are not on the plugin list, on the wiki.

Regardless, Ill have some more stuff to push in the future. Something to consider, is to add the plugin to oh-my-zsh. Perhaps to the external plugins?

[Dbz]

I think this is a good suggestion, and I've been mulling it over. Now that you've helped turned this into something actually useful, I think it's a good idea.

[patmessina]

Do you have a problem adding a little awk into the mix? Being able to search for things across namespaces with regular expressions is useful. In particular, I have

# Search for regular expression across all resources and namespaces
kfind <regular expression> 

# kpfind restricts search to pods with the same usage. An example is to search for all running pods
kpfind Running

[Dbz]

Totally cool with adding awk 👍

[patmessina]

Next things Im going to work on:

• Add functions to README, or at least have the help command.
• Add more functionality for removing/restarting pods

[Dbz]

👍 awesome

[Dbz]

So, I think I might make a PR to switch this to a bash plugin rather than explicitly a zsh plugin. That way more people can use it if they would like to with no effect on the zsh users.

[patmessina]

I believe it is currently incompatible with bash. I'm not opposed to changing it to a bash plugin, and think I would prefer that.

Edit: It would not take long at all to convert what is incompatible though. I think it is just the read commands.

[patmessina]

Ill work on getting a bash version going soon, particularly as I will have some use for it. Would we want to have a separate project?

[Dbz]

I've been thinking about that. I think the name zsh-kubernetes will be pretty confusing for non-zsh users. I also think there is some risk in just renaming the project because it could be confusing.

So, it looks like we have three options:

1. Rename
2. Fork and rename
3. New repo

Looking at the Github docs for renaming a repository

When you rename a repository, all existing information, with the exception of Project Pages URLs, is automatically redirected to the new name
...
In addition to redirecting web traffic, all git clone, git fetch, or git push operations targeting the previous location will continue to function as if made on the new location.

So, simply renaming is a viable option. The benefits of keeping the same repository is that all forks will automatically still point to this repo.

So, I'm open to any of the three options, but I think renaming may be best. Either way we will need to come up with a new name.

Off the top of my head I've got kubernetes-helpers and kubernetes-aliases (kubernetes can also be swapped with k8s), but I'll happily defer to you on the name.

[patmessina]

I think renaming is fine. How about kube-aliases?

[patmessina]

Another idea, I have been writing a script to create small base templates for deployments, jobs, etc. Would we want to add that functionality? The aim is just to create a base yaml file, and I don't think it should really become anything more than that.