Add kubefed validation webhook

[font]

NOTE: This PR is not reviewable until #857 #867 is merged.

This adds the scaffolding to enable kubefed webhook validation for core API types we plan to move to beta. Particularly the 2 APIs added for validation in this PR:

1. FederatedTypeConfig: currently only verifies target kind is set.
2. FederatedCluster: no validation at the moment.

This PR can be merged (pending #857 #867 merging) as follow-on work/discussion is needed to implement the actual validation pieces.

@pmorie did all the work here. I've just mainly added scaffolding for FederatedCluster while cleaning up the history, fixing few chart and deployment issues, etc.

TODO in follow-up PRs:

• Implement validation pieces for core API types moving to beta
• Add support for using k8s CA instead of self-generated one
• Tests

[marun]

Before WIP is removed, I'd like to see the reviewable changes squashed down to as few orthogonal commits as possible and highlighted for potential reviewers. The amount of unreviewable content in this PR makes reviewing via 'Files Changed' all but impossible, and having to review changes commit by commit only works if the commits are few in number and easily identifiable as orthogonal.

[font]

@marun Is this more manageable now that deps have been merged separately?

[font]

I've rebased and this is now ready for review.

[shashidharatd]

@font, is there any particular reason this PR not using the scaffolding provided by kubebuilder for webhooks? https://book.kubebuilder.io/beyond_basics/webhook_installer_generator.html

[xunpan]

+1 with @shashidharatd. With kubebuilder, we do not need to maintain an independent webhook binary. It seems simpler.

[pmorie]

@font, is there any particular reason this PR not using the scaffolding provided by kubebuilder for webhooks? https://book.kubebuilder.io/beyond_basics/webhook_installer_generator.html

From what I was able to tell, the kubebuilder support for webhooks is very minimal and depends on you using a particular controller framework which we are not using. We can refactor to it in the future if we want to but ironically using the kubebuilder facility would require significantly more intrusive changes than the approach this PR takes.

we do not need to maintain an independent webhook binary. It seems simpler

We're not adding a new binary; the webhook server is integrated with hyperfed so there will not be a new binary present in the image, just another symlink to hyperfed.

[irfanurrehman]

@font @pmorie I am not sure how is this tested. Is there a plan to introduce testing for these validations at some point?

[pmorie]

@font @pmorie I am not sure how is this tested. Is there a plan to introduce testing for these validations at some point?

Generally validations are tested in unit tests for the validation methods; from an e2e standpoint they're exercised every time an object is created so they are naturally exercised by e2e scenarios. I think it would be fine to add a validation test for the initial validation in this PR in a follow, since the travis job has passed.

WDYT @irfanurrehman

[marun]

'webhook' is a very generic term. Is there a reason not to use a more specific name (e.g. admission-webhook), or is more than admission behavior expected to be implemented?

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: font

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [font]

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

[font]

@marun pending CI passing this should be ready to re-review.

[marun]

Functionally this LGTM. Some reversion of accidental rename changes required (the joy of rebasing after a rename).

[font]

@marun Not sure how some of those got in there as they should never have been conflicts. I've updated. PTAL.

[marun]

LGTM

[irfanurrehman]

/lgtm