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.

[Dbz]

Both of those suggestions sound reasonable to me 👍

[Dbz]

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)

[patmessina]

Ill work on making it a bash plugin.

[Dbz]

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.

[patmessina]

While we are changing plugin to a bash one, perhaps we can add a man page.

[Dbz]

That's a great idea. I'll take a look at the man page format

[patmessina]

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.

[Dbz]

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 👍

[patmessina]

Made a develop branch. It should handle bash and zsh. In zsh autocomplete should be working.

[patmessina]

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

[Dbz]

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 😬

[Dbz]

How about kcon instead of kmkconfig?

[patmessina]

That is fine with me.

[patmessina]

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.

[patmessina]

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.

[Dbz]

kfind, kpfind, kstatus should work in the current namespace and a flag to work in all namespaces.

That sounds like good behavior to me

We should add some testing. Make sure that we are not duplicating aliases, and what not. Make sure things work in bash and zsh.

Yeah, this project is seriously missing specs. The aliases could actually be done in quite a DRY way which makes sure everything is working as suspected. Would we want to use a k8s cluster for testing?

[patmessina]

That is not a bad idea. Are you thinking Minikube? Though it may be possible to mock the return values for kubectl. We don’t need to test for kubectl behavior. I think that’s out of scope.

Definitely started to add a lot more stuff than I initially expected. Was just adding aliases I was commonly using, and some functionality. Definitely can be cleaned up. Perhaps we should explicitly write out the desired features/specs?

[Dbz]

Yeah. However, should we mock the return values, or just wait for kubectl to return them? I feel like if we mock the return values, then we may make a mistake with the test and have it return data it wouldn't.

[patmessina]

That is very true.
Ill get things going this week.

I started a project. Help us keep track with what we are working on. Or we can do something else. Im pretty open.

[Dbz]

That's perfect

[patmessina]

Sorry for not working on it for a bit. I have been caught up at work. Will be doing some stuff this week.

[Dbz]

No worries!

[unixorn]

I just ran across this project, it looks great. I think that the easiest way to make it also be bash-compatible is probably to convert the aliases to scripts in a bin directory and then add:

PLUGIN_BIN="$(dirname $0)/bin"
export PATH=${PATH}:${PLUGIN_BIN}

to the plugin.zsh file.

This also makes it easier to add ruby/python/whatever scripts to the plugin later if you find/write something that isn't a shell script.

[patmessina]

Thank ya. Will be doing this. Assuming Dbz is good with this.

[Dbz]

Oh yeah, this is a great suggestion 👍

[patmessina]

Ive had messages of kd being too easy to delete things, and that kd should be kuebctl describe instead. Perhaps kd could be kdel which is more explicit? This would be breaking. But probably a positive move. Im open to both staying or changing it.

Edit: This would also clear up some issues with kds. kd being kubectl describe seems to be more useful as well.

[Dbz]

I've been thinking about this a lot recently. How do we feel about kdd for delete? dd being the delete line in vim. Just a thought. I think we should be careful to flesh this out as this is a pretty big breaking change.

I think as we get more users, it'll be nice to deprecate before making breaking changes.

[patmessina]

I am a fan of vim bindings, but if we shift describe to kd then kdd should describe a deployment. Im also a fan of having to be slightly more explicit in deleting, as to minimize the likelihood of deleting production things.

I think we should talk a little bit more about the aliases as well. Particularly since this would be breaking. We can make a release, and then start keeping a change log. That way someone could go back if they so choose.

If we automate the creation of the aliases, we should be able to allow users to redefine their own aliases.

Maybe we should get a slack channel/irc/discord and chat about it a bit?

[patmessina]

Trying out some automated function creations. Not final. Also working on playing around with reading custom alias creation.

[Dbz]

@patmessina do you want to join my slack, and we can make a channel to chat about this?

[patmessina]

Done