kube-aliases
kube-aliases copied to clipboard
Suggested Changes
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
tok
- Change
kcl
tok
- Change
n
tons
to represent namespaces and usen
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.
- Change
kc
tok
- Change
kcl
tok
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
tons
to represent namespaces and usen
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.
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.
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.
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?
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.
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
Totally cool with adding awk
👍
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
👍 awesome
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.
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.
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?
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:
- Rename
- Fork and rename
- 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
, orgit 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.
I think renaming is fine. How about kube-aliases
?
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.
Both of those suggestions sound reasonable to me 👍
Okay! I renamed the plugin! 🎉We are now kube-aliases. I also pushed a commit to master removing the environment variable stuff which isn't super useful to the general public.
I think the next big useful thing we can do is make this a bash plugin vs. a zsh plugin. That'll let a lot more people use the plugin (and maybe find it too)
Ill work on making it a bash plugin.
Awesome. I think we'll have to change the filetype, and perhaps also have a .plugin.zsh file that loads our main code so that zsh still can locate the plugin. I can also do some research.
While we are changing plugin to a bash one, perhaps we can add a man page.
That's a great idea. I'll take a look at the man page format
Do you think I could be made a contributor? If so, I would like to structure master to require all merges to be reviewed, and start a develop branch that we can merge into from any feature branches. Understand if this is not something you want to do.
I could swear I had already added you as a contributor. Definitely feel free to make as many changes as you'd like. I trust your judgement 👍
Made a develop branch. It should handle bash and zsh. In zsh autocomplete should be working.
In the develop branch, kmkconfig
can now create templates of a few different files. I will expand on this soon. I'm not particularly fond of the name for that currently. So if you think of something nice, let me know. Docs still need to be updated for it, but I am going to wait until I am finished with that. To try it out, run kmkconfig -h
Sorry, I haven't been responding in a timely manner. I think the changes you're making are great. I'll ponder the kmkconfig
. I agree that's not easiest name 😬
How about kcon
instead of kmkconfig
?
That is fine with me.
Lets not merge. I want kstatus to grab everything in the current namespace, and a flag or something to grab it across all namespaces. Currently, it grabs across all namespaces. Probably should be able to specify which namespace to run this on.
Things Im thinking about.
- kfind, kpfind, kstatus should work in the current namespace and a flag to work in all namespaces.
- We should add some testing. Make sure that we are not duplicating aliases, and what not. Make sure things work in bash and zsh.