Add backup-diff plugin to index

[milapj]

• backup-diff creates a backup of a resource and compares the change between the backed-up state at a specific point in time and the current state, showing the state drift.

• Functions similar to git diff. This can be pretty useful during disaster recovery or debugging to recover previous states of resources that were updated on the fly w/o having to re-release.

• The backup is stored at /tmp/backups/<resource-type> by default, but it can be stored at a user-specified path. The resources can also be re-created using the backup files.

• github repo

kubectl-backup-diff-compressed.mp4

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: milapj / name: Milap Jhumkhawala (233bac4, 252f0a6, e8f5d83)

[ahmetb]

🤖 Beep beep! I’m a robot speaking on behalf of @ahmetb. 🤖

---

Thanks for submitting your kubectl plugin to Krew!
One of the krew-index maintainers will review it soon. Note that the reviews for new plugin submissions may take a few days.

In the meanwhile, here are a few tips to make your plugin manifest better:

• Make sure your plugin follows the best practices.
• Eliminate redundant wording form shortDescription (it should be max 50 characters).
• Try to word wrap your description to 80-character lines (no usage examples, please).

Thanks for your patience!
/kind new-plugin

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: milapj
Once this PR has been reviewed and has the lgtm label, please assign corneliusweig for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Welcome @milapj!

It looks like this is your first PR to kubernetes-sigs/krew-index 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/krew-index has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[ahmetb]

Thanks for the submission. Based on your description, this is not too different than what a few UNIX tools and existing plugins offer, e.g.

kubectl get RESOURCE | kubectl neat (or eksporter) > 1.yaml
kubectl edit RESOURCE
kubectl get RESOURCE | kubectl neat (or eksporter) > 2.yaml 
diff -y 1.yaml 2.yaml

In these situations, we typically encourage use of existing tools and UNIX tool composability principle instead of creating a separate plugin for every combination tools. These plugins tend to go unmaintained over time, which benefits neither the users nor the maintainer.

[milapj]

Thanks for the submission. Based on your description, this is not too different than what a few UNIX tools and existing plugins offer, e.g.

kubectl get RESOURCE | kubectl neat (or eksporter) > 1.yaml
kubectl edit RESOURCE
kubectl get RESOURCE | kubectl neat (or eksporter) > 2.yaml 
diff -y 1.yaml 2.yaml

In these situations, we typically encourage use of existing tools and UNIX tool composability principle instead of creating a separate plugin for every combination tools. These plugins tend to go unmaintained over time, which benefits neither the users nor the maintainer.

well, there are quite a few plugins in the index whose behavior can be replicated using stock kubectl + unix commands. This plugin offers a way to keep track of the state per time per resource, which can be accessed via a pointer. Your proposed solution can get messy really quickly, users might want to write a shell script anyway (like I did). That's the reason I wrote this plugin.

Just to gather some feedback -

• Is there a specific functionality you'd like to see this plugin offer in the space of resource state drift?
• Is there a better way to handle the output needed?

[ahmetb]

well, there are quite a few plugins in the index whose behavior can be replicated using stock kubectl plugins + unix commands.

We try to keep those to a minimum (and they might be added before we started questioning usefulness of plugins). We historically rejected many plugins because they could be achieved by putting together 1-2 commands or pipes, or using other kubectl plugins. If you look at label gray-area you'll find plenty of examples.

You cited scenarios like disaster recovery, but I am assuming the plugin works on only one resource at a time. I don't think this is all that much different than the snipped I listed above. For example, if I wanted to back up all resources, I would use kubectl get-all today. If I wanted to back up a single resource, I probably would use kubectl get KIND -A. On top of that, the idea of backup/restore only rarely works (given some resources have ordering relationships between them, or webhooks enforcing a particular state).

In the past, I've given plugin authors advice to do some user research, and listen to feedback to come up with actually useful plugins that solve an actual problem. It's really easy to implement some plugin idea by hacking a few lines of a bash script, but that doesn't make the tool broadly useful.

Hope you understand my point –if we accepted every single plugin, it would be an enormous dumping ground. So we try to do our best to curate the list. Also, you can still distribute your plugin via Krew using custom indexes: https://krew.sigs.k8s.io/docs/developer-guide/custom-indexes/ That way, users can still install your plugin via Krew, but they'll be downloading the plugin manifest from your repository instead of krew-index.

[milapj]

well, there are quite a few plugins in the index whose behavior can be replicated using stock kubectl plugins + unix commands.

Hope you understand my point –if we accepted every single plugin, it would be an enormous dumping ground. So we try to do our best to curate the list. Also, you can still distribute your plugin via Krew using custom indexes: https://krew.sigs.k8s.io/docs/developer-guide/custom-indexes/ That way, users can still install your plugin via Krew, but they'll be downloading the plugin manifest from your repository instead of krew-index.

I do understand your point and I agree with it. Wouldn't want krew to become like npm hah. Well, I guess I'll come back with some other new idea for a plugin. Cheers!

[milapj]

closing this PR, thanks @ahmetb, for your feedback