Add inline plugin

[huuff]

A simple plugin to quickly create resources from the command line with your $EDITOR

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: huuff / name: Haf (e5af2e14da560b40fc9729fbc1851653a5814c7a)

[ahmetb]

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

---

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: huuff Once this PR has been reviewed and has the lgtm label, please assign corneliusweig for approval by writing /assign @corneliusweig in a comment. 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 @huuff!

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. :smiley:

[ahmetb]

This is a good idea and thanks for your submission. However, kubectl example plugin is pretty close to this (it doesn't launch an $EDITOR, maybe). It could be better for the community if the two plugin authors can collaborate and maintain a single plugin with the same set of templates to offer a single plugin for this. What do you think?

[huuff]

Hi Ahmet,

I would argue that example and inline have different purposes and that example is already good at its. I wrote kubectl-inline to aid in quick experimentation, while example prints examples that can be useful as a reference, so I think there might be conflicting interests:

• example finds useful to have highly detailed resources, that have more uncommon fields. The user would invoke it to get a quick reminder of the structure of some attribute they don't remember
• inline on the other hand benefits from having smaller resources, since it's made to quickly create a simple resource it'd be bothersome to get an example with a lot of filled-in fields and extra attributes you'd need to delete in your $EDITOR

However, I'm aware inline is very bare-bones and not all that useful at its current state (I'm writing it for scratching personal itches and add features as I need them). example provides many more resource types to create, for example. I wouldn't want to pollute the krew index with a low-quality plugin, so maybe would it be OK if I resubmit it once it's more complete and differentiated?

Some features I'm missing:

• A few more resources
• Completing some resource fields directly from command-line flags
• Command-line flags to quickly provide more or less complex templates on demand. I'm against giving the user a pod template with an initContainer section, unless, of course, that's what they're experimenting with. I have yet to find a way of providing a nice interface for this,

[ahmetb]

Typically if a plugin's entire functionality can be achieved through one-liners, e.g. putting kubectl example and $EDITOR together through pipes, we tend to shy away from accepting those plugins, and expect to have notable value add.

so maybe would it be OK if I resubmit it once it's more complete and differentiated?

Indeed. I also recommend spending a lot more time on developing this plugin and seeing what unique experience can you provide. This might be a great tool, if designed with the right user experience.

• Completing some resource fields directly from command-line flags

FWIW command-line tab completion doesn't work for kubectl plugins at the moment.