-
Notifications
You must be signed in to change notification settings - Fork 420
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ClusterInterceptor CRD for registering interceptors #960
Conversation
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
/cc @savitaashture @wlynch @MarcelMue @bigkevmcd I broke off #921 into multiple PRs. One change I did was to call the CRD InterceptorType instead of just Interceptor to indicate that it defines a new type or kind of interceptor. |
The following is the coverage report on the affected files.
|
docs/interceptortypes.md
Outdated
--> | ||
# InterceptorType | ||
|
||
A `InterceptorType` is cluster scoped resource that registers a new Interceptor that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 100% sure we want this to be cluster scoped. In particular, I'm thinking about how we can expose custom interceptors that can only be used within a single tenant namespace.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If its not cluster scoped, each new namespace would have to install their own version of Interceptors....could we not use RBAC to restrict if certain interceptors need to be limited?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
chatted with @wlynch about this. We will start off with a cluster scoped CRD but will implement a Namespace scoped version of this in the future as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Let's update the docs to reflect the change.
|
||
// InterceptorTypeSpec describes the Spec for an InterceptorType | ||
type InterceptorTypeSpec struct { | ||
ClientConfig ClientConfig `json:"clientConfig"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we reuse WebhookClientConfig?
At the very least we can likely reuse the ServiceReference if we want to use the apis.URL for URL. The cert data is also useful for HTTPS.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think using a WebhookClientConfig is a good idea - maybe just reimplementing the type here if we are concerned about dependencies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I am basically reimplementing the type here....two differences:
- using apis.URL instead of string for the URL type for better validation/json marshalling
- we do not have a
caCert
field type (yet!) for HTTPS
Pulling in a new dependency for just the two structs seems much so I decided to copy the structs. It also allows us to make changes (e.g. making the port a *int instead of int as suggested below)
docs/interceptortypes.md
Outdated
|
||
## Syntax | ||
|
||
To define a configuration file for an `Interceptor` resource, you can specify |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bikeshed: I kind of like InterceptorConfiguration to be consistent with ValidatingWebhookConfiguration.
Other good ideas to borrow from admission webhooks we should look into later:
- Version info (e.g. have different routes based on interceptor version)
- Timeout
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmmm yeah...this CRD is definitely based on the WebhookConfiguration CRDs....I don't have a strong preference on calling this InterceptorConfguration or something else --> I thought it was a bit confusing in the sense its not clear if it is some interceptor configuration that can be reused within a trigger vs configuration for a new kind of interceptor.
The InterceptorType name can be a bit awkward a times too though like we now have a file called interceptor_type_types.go
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally don't love the Configuration
suffix. It makes sense if we have a different Interceptor
object but a Configuration
suffix without an Interceptor
CRD seems weird to me.
No strong opinions though.
The following is the coverage report on the affected files.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm w/ minor doc changes.
Since this is a new type, would appreciate a second pair of eyes as an approver!
docs/clusterinterceptors.md
Outdated
- [Interceptors](#interceptors) | ||
- [Syntax](#syntax) | ||
- [clientConfig](#clientConfig) | ||
|
||
## Syntax | ||
|
||
To define a configuration file for an `Interceptor` resource, you can specify | ||
the following fields: | ||
|
||
- Required: | ||
- [`apiVersion`][kubernetes-overview] - Specifies the API version, for example | ||
`triggers.tekton.dev/v1alpha1`. | ||
- [`kind`][kubernetes-overview] - Specifies the `Trigger` resource | ||
object. | ||
- [`metadata`][kubernetes-overview] - Specifies data to uniquely identify the | ||
`Interceptor` resource object, for example a `name`. | ||
- [`spec`][kubernetes-overview] - Specifies the configuration information for | ||
your Interceptor resource object. The spec include: | ||
- [`clientConfig`] - Specifies how a client (e.g. an EventListener) can communicate with the Interceptor. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few more Interceptor -> ClusterInterceptor replacements need to be made in here.
/cc @sergetron for a docs review! |
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
/test pull-tekton-triggers-integration-tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
This commit adds a new CRD type called ClusterInterceptor. In TEP-0026 this type was called InterceptorConfiguration The `spec` currently only contains a clientConfig field to locate where the interceptor is running. Other fields will be added as they are implemented in follow ups. This commit also adds a simple reconciler for this type that resolves the clientConfig to a URL and adds it to the `status.address.url` field. Part of tektoncd#868 Signed-off-by: Dibyo Mukherjee <[email protected]>
The following is the coverage report on the affected files.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: savitaashture, wlynch 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:
Approvers can indicate their approval by writing |
Changes
This commit adds a new CRD type called ClusterInterceptor. In TEP-0026 this
type was called InterceptorConfig
The
spec
currently only contains a clientConfig field to locate wherethe interceptoris running. Other fields will be added as they are
implemented in follow ups.
This commit also adds a simple reconciler for this type that resolves
the clientConfig to a URL and adds it to the
status.address.url
field.Part of #868
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
See the contribution guide for more details.
Release Notes