Issue 7, 156: Admission webhook

[Tristan1900]

Change log description

• Add admission webhook that supports version validation
• Add unit test
• Add e2e test

What the code does

There are two concepts here, the admission webhook server and the admission webhook. Admission webhook server is like an http server that serves the incoming requests. Admission webhook implements the application logic and register itself to the webhook server, there are two kinds of admission webhook, mutating admission webhook and validating admission Webhook, right now we only use mutating admission Webhook. The admission webhook server starts in the Operator pod with a fronting k8s service. When requests come into k8s, apiserver will route the request to that service and the backend admission webhook server will get that request and call the admission webhook for processing. The port that admission webhook server listens to is port 443. To bind port 443, we need to grant permission to Operator process using setcap CAP_NET_BIND_SERVICE=+eip.

There is a supported version list in our webhook. Any requests with an invalid Pravega version will be rejected. For example 0.6.0 is an invalid Pravega version because there is no such released version yet. There is also a supported upgrade path in our webhook, it will reject the request if the upgrade is not supported. For example, rolling upgrade from 0.3.0 to 0.4.0 is not supported. However, any upgrade to patch version is supported, such as 0.4.0 to 0.4.1.

Purpose of the change

• Fix Admission Controller for PravegaCluster resource #7
• Fix Validate upgrade requests #156

How to test the change

Tests should pass

---

Signed-off-by: wenqi [email protected]

[adrianmo]

@Tristan1900 you did a great work with the admission webhook! I've added a few comments through the code :)

[Tristan1900]

Thanks @adrianmo for the comments and changes! Could you please review it again? Thanks!

[adrianmo]

@Tristan1900 thanks for updating the PR and addressing my comment. It looks good, but I'm worried about one thing. We have lost the ability to run the operator locally, which has been very useful for testing out changes during the development. Have you investigated if it's there a way to re-enable it again? If we can't find a way and the webhook server is causing issues, it'd be OK from my side to explicitly disable the webhook when running the operator locally. What do you think?

[Tristan1900]

@adrianmo Thanks for pointing that out! It makes sense to disable webhook when using up local. I made the change last Friday to address this but forgot to reply to your comments. Sorry about that. I see you've merged this PR, thanks for the review!