Add plugin: kubeval

[nlamirault]

This plugin allow for running kubeval , a tool for validating a Kubernetes YAML or JSON configuration file.
It does so using schemas generated from the Kubernetes OpenAPI specification, and therefore can validate schemas for multiple versions of Kubernetes.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: nlamirault
To complete the pull request process, please assign ahmetb
You can assign the PR to them by writing /assign @ahmetb in a comment when ready.

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

[ahmetb]

supports multiple Kubernetes versions

part is redundant for a "short" description, it's better to actually keep it short.

[ahmetb]

you can also use the description field if necessary.

[ahmetb]

Normally we don't accept plugins with kube* prefix, but since this is a well-established tool it qualifies for an exception to preserve its name.

However, this also might be an opportunity for you to rename and distribute your tool as kubectl validate-config.

I also recommend making sure the help (-h/--help) message for kubectl kubeval shows invocation/examples as "kubectl kubeval" and not just "kubeval" when invoked as a plugin.

[ahmetb]

@nlamirault what’s your take on the naming? Should we keep the existing name fi it's well-recognized, or do you want your users to be primarily invoking it like kubectl validate-config?

[nlamirault]

we can ask the author of the plugin what he thinks ?
Ping @garethr

[corneliusweig]

@garethr Have you seen the PR regarding kubeval in krew-index? We are discussing how the plugin should be named. Maybe you can share your thoughts here?

[garethr]

Mmm, turning it into a general question about Krew index opinions again :)

validate-config would basically mean kubeval is the way of validating config. If something else exists, or comes along later, it's locked out or hidden behind an upstream abstraction or has to adhear to the same interface.

For that reason, I'd suggest plugins carry the name of the underlying tool. That also makes support less surprising. If kubeval is hidden then users won't find it easy to file issues in the right place. But I'm of the view the Krew index should be less opinionated I think.

[ahmetb]

Regarding naming:

• We've been preserving the original names of plugins that are already popular. We can do the same here.
• kubectl kubeval sounds odd (and the stutter is something we try to avoid), and as Gareth said, kubectl validate-config hides the fact that it's actually kubeval.

Regarding distributing as a plugin:

kubeval already has packaging for Windows, Linux, macOS. Why does it make sense to add yet another distribution (krew)?

At this point, I don't think it even makes sense to stop distributing with existing methods and use Krew. That would leave existing users behind. Also, krew helps plugins which haven't created distributions for multiple OSes yet, but kubeval is already there.

Does kubeval benefit from being a krew plugin? Maybe the users can benefit, as they can declaratively install most of their kubernetes client-side tooling via krew. But overall, I'm not even sure if that's a huge benefit.

[garethr]

Does kubeval benefit from being a krew plugin? Maybe the users can benefit, as they can declaratively install most of their kubernetes client-side tooling via krew. But overall, I'm not even sure if that's a huge benefit.

From a users perspective, discovery and central management are useful in my view. That's normally the whole point of a package manager. See Homebrew as a good example.

I think the Krew project needs to make clear it's not intending to be a generic package manager for Kubectl plugins, rather it's a very opinionated distribution of Kubectl plugins.

I think that's fine, but I do think that leaves a gap in the market for a registry/tool for discovering/ managing any and all kubectl plugins. At least until/unless Krew adds the ability to have additional search paths (at which point I'd be happy to create the equivalent of a Homebrew tap) for this plugin definition.

[corneliusweig]

So if I understand both of you correctly, you both agree (for maybe different reasons) to not include kubeval as a plugin in krew, right?

[garethr]

@corneliusweig I'd be happy to see it included under kubeval. I think it would aid discovery and, for some users, aid installation and management.

[ahmetb]

@garethr Yeah we can release it as a plugin. Some cooperation required from your side would be:

• Make releases on Krew for new versions occassionally (it's on our radar to bump plugin versions automatically via github releases, we're not there yet).
• Make sure your --help message and other USAGE strings show kubectl kubeval when the program is invoked as a plugin (you can tell this via argv[0] ends with kubectl-kubeval).

At any rate, please review this PR for accuracy of description etc.

[garethr]

@ahmetb sounds good. Issue on kubeval opened instrumenta/kubeval#187

Not sure if you're using CODEOWNERS or similar? I'm seeing some multi-user repos do similar. Happy to be added if useful.

The description and other details look correct, thanks @nlamirault for submitting.

[ahmetb]

I am not sure if Kubernetes/prow has support for CODEOWNERS so we aren’t doing that. Also I am not sure how it is relevant and what you have in mind to achieve with it.

[garethr]

@ahmetb spurred by a conversation today regarding tekton https://github.com/tektoncd/catalog/pull/104/files. They are starting to use owners as a way of scaling shared content and routing issues.

[ahmetb]

Yeah, we don't have a per-plugin directory structure to support that. We already have the standard OWNERS files and we know who the owners are. I hope I'm not missing something.

[ahmetb]

@nlamirault do you have time to help instrumenta/kubeval#187, then we can merge this as kubectl kubeval.

/retitle Add plugin: kubeval

[corneliusweig]

Please also install a LICENSE file

[corneliusweig]

The archive already includes a LICENSE file, so you can simply copy out another file like so:

- from: LICENSE
  to: .

[corneliusweig]

Let's resolve this PR in one or the other way. I think the manifest is in good shape and could be merged.

From the discussion above, there are a few open points:

1. Rename the plugin to kubectl kubeval. Thus existing users can recognize the tool in krew, even though it stutters.
2. Adjust help text when kubeval is run as plugin. As the plugin name kubeval is the same as the standalone binary, this is a nice-to-have but no blocker for merging in my opinion.
3. You need to install the LICENSE file.
4. Get the CI build green.

@nlamirault If these points are addressed, I'm in favor of merging.

[corneliusweig]

Suggested change

	The plugin validate a Kubernetes YAML or JSON configuration file.
	The plugin validates a Kubernetes YAML or JSON configuration file.

[corneliusweig]

The archive already includes a LICENSE file, so you can simply copy out another file like so:

- from: LICENSE
  to: .

[corneliusweig]

Suggested change

	 shortDescription: Validate your Kubernetes configuration files
	 shortDescription: Validate schema of resource files

[corneliusweig]

Suggested change

	 name: validate-config
	 name: kubeval

[ahmetb]

If nobody’s signing up to maintain this manifest, I suggest we don’t proceed. We equally need support from kubeval to look like a plugin (help msgs etc, and release bundle not breaking).

[nlamirault]

@ahmetb @corneliusweig i just push a commit with your remarks

[corneliusweig]

So to sum up @ahmetb's concerns:

1. Who will maintain this manifest? My current assumption is that @nlamirault wants to do this, correct?
2. Release bundle not breaking. This is also @nlamirault's task if he's going to maintain this manifest.
3. Help messages for plugin usage: because the plugin is called the same as the standalone, this should be fine for now. Or do you see potential for big confusion here?

Provided that @nlamirault agrees to maintain this manifest, I'm still supportive of merging.

[corneliusweig]

The indentation of these two fields is wrong. Please fix this to get the CI to pass.

[corneliusweig]

@nlamirault Nothing has happened here for almost a month. If you don't plan to continue, could you please close the issue?

[ahmetb]

/close
Kubeval is already popular outside krew and there doesn’t seem to be enough interest to pursue this. So I will close.

[k8s-ci-robot]

@ahmetb: Closed this PR.

In response to this:

/close
Kubeval is already popular outside krew and there doesn’t seem to be enough interest to pursue this. So I will close.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.