-
Notifications
You must be signed in to change notification settings - Fork 419
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
Enhance existing eventlistener to support PodTemplate for Deployment using duck type #734
Conversation
/cc @dibyom |
The following is the coverage report on the affected files.
|
f16278a
to
048bb6b
Compare
The following is the coverage report on the affected files.
|
048bb6b
to
a4d9fff
Compare
The following is the coverage report on the affected files.
|
@savitaashture: PR needs rebase. 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. |
a4d9fff
to
c89b35f
Compare
The following is the coverage report on the affected files.
|
@savitaashture are you planning on getting this for v0.8 or v0.9? |
@savitaashture: PR needs rebase. 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. |
c89b35f
to
7e23367
Compare
The following is the coverage report on the affected files.
|
7e23367
to
ee8a9f9
Compare
The following is the coverage report on the affected files.
|
ee8a9f9
to
5f3813f
Compare
The following is the coverage report on the affected files.
|
5f3813f
to
6fa5c4b
Compare
The following is the coverage report on the affected files.
|
// for backward compatibility with original behavior | ||
var serviceType = el.Spec.ServiceType | ||
if el.Spec.Resources.KubernetesResource != nil && el.Spec.Resources.KubernetesResource.ServiceType != "" { | ||
serviceType = el.Spec.Resources.KubernetesResource.ServiceType |
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.
Do we also want to add some defaulting logic in el.SetDefaults to change el.Spec.ServiceType to el.Spec.Resources.KubernetesResource.ServiceType?
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 we don't require because even if ServiceType
is empty k8s itself set ClusterIP
as default
WDYT?
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.
Oh, what I meant by defaulting is something like
if el.Spec.ServiceType != nil {
el.Spec.Resources.KubernetesResource.ServiceType = el.Spec.ServiceType
This is so that we can deprecate/remove the el.Spec.ServiceType
field later.
serviceAccountName string | ||
) | ||
podlabels = mergeMaps(el.Labels, GenerateResourceLabels(el.Name)) | ||
|
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.
same comment as with serviceType
-> it seems like we could also do some of this in the webhook via EL's SetDefaults.
if el.Spec.Resources.KubernetesResource.Template.Spec.ServiceAccountName != "" { | ||
serviceAccountName = el.Spec.Resources.KubernetesResource.Template.Spec.ServiceAccountName | ||
} | ||
annotations = el.Spec.Resources.KubernetesResource.Template.Annotations |
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.
Don't we also have to mergeMaps for annotations too like we do in 7622d51
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 feel we don't require here because these are part of deployment.spec.template.metadata
and there won't be any annotations which are added by k8s, So we don't get continuous loop issue.
So deployment.spec.template.metadata.annotation
will add/update to annotations value if provided as part of el.Spec.Resources.KubernetesResource.Template.Annotations
even if user manually edit those directly on deployment it will not allow same like others.
Let me know if you have some other point to address
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.
Hmm, yeah you are right...I was confusing deployment.spec.template.metadata.annotations
with deployment.metadata.annotations
. I think this is fine then 👍
Kind of off topic, the reconciler code is getting kind of long and unwieldy, we might want to see how we can refactor/clean it up a bit. I'll open an issue.
6fa5c4b
to
10fc888
Compare
The following is the coverage report on the affected files.
|
@@ -313,3 +320,37 @@ func EventListenerCELOverlay(key, expression string) EventInterceptorOp { | |||
} | |||
} | |||
} | |||
|
|||
// EventListenerResources set specified resources to the EventListener. |
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.
In pipelines, we've been trying to get rid of test builders and use structs as much as possible. For our reconciler tests too, we've started using single make(EL/Deployment/Service) functions. I think its ok to keep for now, but later we might end up removing builders just like in Pipeline.
Just a couple of small unresolved issues around defaulting (I think its ok to add them in a follow up if you want!) |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dibyom 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 |
I shall add it in follow up PR Thank you 👍 |
/lgtm |
Changes
Fix: #727
As described in the issue the feature is part of TEP and addresses supporting podtemplate duck type to kubernetes resources.
Signed-off-by: Savita Ashture sashture@redhat.com
/kind feature
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
A new field
resources
has been introduced as part of EventListener specresources
field mainly contains information that whether the resource is built inkubernetes
orcustom
As of now
resources
field supportkubernetesResource
which helps to use PodSpecable ducktype and with the help of ducktype can avoid specifyingserviceAccountName
,serviceType
andpodTemplate
as part of eventlistener specAs of now for backward compatibility both way supported and
resources
are optional.Once we deprecate old way then
resources
field becomes mandatory if anyone wants to specifyserviceAccountName
,serviceType
andpodSpec
.Advantages
Including
kubernetesResource
as part ofresources
helps to make use of PodSpecable duck typeand this way we can avoid hardcoding of podSpec fields as part of
podTemplate
.Including
customResource
as part ofresources
will help triggers to make use of any CRDex: Knative Service
which helps triggers to get the serverless functionality.this is not supported as part of this PR but will continue as part of this TEP