Skip to content
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

EventType autocreate #3585

Merged
merged 31 commits into from
Feb 27, 2024
Merged

Conversation

Cali0707
Copy link
Member

Fixes #3174 #3181

Proposed Changes

  • Create an EventTypeCreator class to handle the creation of eventtypes
  • Call the create method in the receiver ingress on successfully receiving an event

These changes work as follows:

kn broker create my-broker --class Kafka
Broker 'my-broker' successfully created in namespace 'default'.

 kn-event-linux-amd64 send --to Broker:eventing.knative.dev/v1:my-broker --type type.eventing.example.1
Jan 10 12:35:42.087   INFO Event (ID: e0a551a7-7f1e-482e-aaa0-10fc5c076326) have been sent.

kubectl get eventtypes.eventing.knative.dev -A
No resources found

kubectl apply -f enable-autocreate.yaml                           
configmap/config-features configured

kn-event-linux-amd64 send --to Broker:eventing.knative.dev/v1:my-broker --type type.eventing.example.1
Jan 10 12:52:07.555   INFO Event (ID: a8c83ebf-d8a6-4fb0-9fb1-c2d67f8a21e9) have been sent.

kubectl get eventtypes.eventing.knative.dev -A                                                        
NAMESPACE   NAME                                            TYPE                      SOURCE             SCHEMA   REFERENCE NAME   REFERENCE KIND   DESCRIPTION                             READY   REASON
default     et-my-broker-cc78b6ed9ee7697817cf61de134725aa   type.eventing.example.1   kn-event/v1.10.0            my-broker        Broker           Event Type auto-created by controller   True    

Release Note

:gift: EventType Autocreate now works for the Eventing Kafka Broker and Eventing Kafka Channel

Docs

Signed-off-by: Calum Murray <cmurray@redhat.com>
Signed-off-by: Calum Murray <cmurray@redhat.com>
Signed-off-by: Calum Murray <cmurray@redhat.com>
Signed-off-by: Calum Murray <cmurray@redhat.com>
Signed-off-by: Calum Murray <cmurray@redhat.com>
Signed-off-by: Calum Murray <cmurray@redhat.com>
Signed-off-by: Calum Murray <cmurray@redhat.com>
Signed-off-by: Calum Murray <cmurray@redhat.com>
@knative-prow knative-prow bot requested review from creydr and Leo6Leo January 10, 2024 18:10
@knative-prow knative-prow bot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. approved Indicates a PR has been approved by an approver from all required OWNERS files. area/control-plane area/data-plane labels Jan 10, 2024
@Cali0707
Copy link
Member Author

/cc @Leo6Leo @pierDipi @matzew

@Cali0707 Cali0707 changed the title Et autocreate EventType autocreate Jan 10, 2024
Copy link

codecov bot commented Jan 10, 2024

Codecov Report

Attention: Patch coverage is 56.42857% with 61 lines in your changes are missing coverage. Please review.

Project coverage is 62.10%. Comparing base (049d0f0) to head (49c3372).
Report is 2 commits behind head on main.

Files Patch % Lines
...tive/eventing/kafka/broker/receiver/main/Main.java 0.00% 23 Missing ⚠️
...ing/kafka/broker/core/eventtype/EventTypeSpec.java 35.71% 18 Missing ⚠️
...ceiver/impl/handler/IngressRequestHandlerImpl.java 38.46% 7 Missing and 1 partial ⚠️
control-plane/pkg/reconciler/broker/controller.go 42.85% 2 Missing and 2 partials ⚠️
control-plane/pkg/reconciler/sink/controller.go 42.85% 2 Missing and 2 partials ⚠️
...ka/broker/core/eventtype/EventTypeCreatorImpl.java 89.47% 2 Missing and 2 partials ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##               main    #3585      +/-   ##
============================================
- Coverage     62.16%   62.10%   -0.06%     
- Complexity      859      874      +15     
============================================
  Files           189      190       +1     
  Lines         12937    13037     +100     
  Branches        276      284       +8     
============================================
+ Hits           8042     8097      +55     
- Misses         4265     4303      +38     
- Partials        630      637       +7     
Flag Coverage Δ
java-unittests 74.13% <57.93%> (-0.39%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@Cali0707
Copy link
Member Author

/test upgrade-tests

Signed-off-by: Calum Murray <cmurray@redhat.com>
@Leo6Leo
Copy link
Contributor

Leo6Leo commented Jan 10, 2024

@Cali0707 Tested in my local environment, the event type works perfectly! Great work!!!

Copy link
Member

@pierDipi pierDipi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you also planning to add E2E tests ?

Comment on lines +49 to +50
this.messageDigest.reset();
this.messageDigest.update(suffixString.getBytes());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what happens when this is called concurrently ? I guess this is not thread safe ?

Copy link
Member Author

@Cali0707 Cali0707 Jan 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I doubt this is thread safe, but currently it is just used in the IngressRequestHandlerImpl which I thought was 1 per verticle (so no concurrency worries?). Should I change this to be thread safe?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I would opt to being safer here

Comment on lines +51 to +56
final var suffix = Hex.encodeHexString(this.messageDigest.digest());
final var name = String.format("et-%s-%s", reference.getName(), suffix).toLowerCase();
if (name.length() > DNS1123_SUBDOMAIN_MAX_LENGTH) {
return name.substring(0, DNS1123_SUBDOMAIN_MAX_LENGTH);
}
return name;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the same algorithm we use in Eventing core ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines 59 to 65
private boolean eventTypeExists(String etName, DataPlaneContract.Reference reference) {
var et = this.eventTypeClient
.inNamespace(reference.getNamespace())
.withName(etName)
.get();
return et != null;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we using an actual client ? should we use a lister here ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an actual client as I wasn't sure how to make a lister to our custom class - I'll try and update it to be a lister

.withSchema(event.getDataSchema())
.withDescription("Event Type auto-created by controller");

this.eventTypeClient.resource(et.build()).create();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should avoid failing when the resource exist (like when it is created by some other process between checking exists and this line)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm yeah, as far as I can tell this method doesn't declare that it returns an error or throws an exception. Should I wrap this in a try catch just in case?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to be sure on what happens when already exists and handle that case accordingly

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked on their github and they said that the methods generally throw exceptions, so I'll add a try-catch to handle that case

@Cali0707
Copy link
Member Author

For E2E tests, I was planning on porting those from eventing core: https://github.com/knative/eventing/blob/42af160c3cfc244e26fa7bcd5db2c670ebdcf326/test/experimental/eventtype_autocreate_test.go#L32-L74

But, I'm not sure if we have a job for experimental tests so I think I need to set that up first

Signed-off-by: Calum Murray <cmurray@redhat.com>
@Cali0707
Copy link
Member Author

/test

Copy link

knative-prow bot commented Jan 15, 2024

@Cali0707: The /test command needs one or more targets.
The following commands are available to trigger required jobs:

  • /test build-tests
  • /test channel-integration-tests-sasl-plain
  • /test channel-integration-tests-sasl-ssl
  • /test channel-integration-tests-ssl
  • /test channel-reconciler-tests-sasl-plain
  • /test channel-reconciler-tests-sasl-ssl
  • /test channel-reconciler-tests-ssl
  • /test integration-tests
  • /test reconciler-tests
  • /test reconciler-tests-keda
  • /test reconciler-tests-namespaced-broker
  • /test unit-tests
  • /test upgrade-tests

The following commands are available to trigger optional jobs:

  • /test reconciler-tests-loom
  • /test reconciler-tests-namespaced-broker-loom

Use /test all to run the following jobs that were automatically triggered:

  • build-tests_eventing-kafka-broker_main
  • channel-integration-tests-sasl-plain_eventing-kafka-broker_main
  • channel-integration-tests-sasl-ssl_eventing-kafka-broker_main
  • channel-integration-tests-ssl_eventing-kafka-broker_main
  • channel-reconciler-tests-sasl-plain_eventing-kafka-broker_main
  • channel-reconciler-tests-sasl-ssl_eventing-kafka-broker_main
  • channel-reconciler-tests-ssl_eventing-kafka-broker_main
  • integration-tests_eventing-kafka-broker_main
  • reconciler-tests-keda_eventing-kafka-broker_main
  • reconciler-tests-namespaced-broker_eventing-kafka-broker_main
  • reconciler-tests_eventing-kafka-broker_main
  • unit-tests_eventing-kafka-broker_main
  • upgrade-tests_eventing-kafka-broker_main

In response to this:

/test

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.

Signed-off-by: Calum Murray <cmurray@redhat.com>
@knative-prow knative-prow bot removed the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jan 15, 2024
@knative-prow knative-prow bot removed the lgtm Indicates that a PR is ready to be merged. label Jan 31, 2024
@knative-prow-robot knative-prow-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jan 31, 2024
@knative-prow-robot knative-prow-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Feb 9, 2024
Signed-off-by: Calum Murray <cmurray@redhat.com>
@knative-prow-robot knative-prow-robot added needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. and removed needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels Feb 9, 2024
Signed-off-by: Calum Murray <cmurray@redhat.com>
@knative-prow-robot knative-prow-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Feb 13, 2024
Comment on lines 56 to 60
try {
this.messageDigest = MessageDigest.getInstance("MD5");
} catch (NoSuchAlgorithmException ignored) {
this.messageDigest = null;
}
Copy link
Member

@pierDipi pierDipi Feb 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Catching and leaving it to null will just delay the exception to the runtime, can we just not catch it or if it's unchecked exception, we could wrap it into a runtime exception?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently it doesn't throw a runtime exception, the autocreate just becomes a no-op (no eventtype gets created). Do you think it's better to fail here instead?

Comment on lines 76 to 79
if (this.eventTypeLister == null) {
logger.debug("no eventtype lister, creating eventtype and might run into failure");
return null;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we fail fast here in the constructor?

return eventTypeCreator
.create(event, reference)
.onFailure((exception) -> {
logger.warn("failure occured, closing informer", exception);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"occured" is a misspelling of "occurred"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, thanks!

Signed-off-by: Calum Murray <cmurray@redhat.com>
@Cali0707
Copy link
Member Author

/cc @pierDipi

@knative-prow knative-prow bot requested a review from pierDipi February 20, 2024 14:42
Copy link
Member

@pierDipi pierDipi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/approve

@knative-prow knative-prow bot added the lgtm Indicates that a PR is ready to be merged. label Feb 21, 2024
@knative-prow knative-prow bot removed the lgtm Indicates that a PR is ready to be merged. label Feb 21, 2024
@Leo6Leo
Copy link
Contributor

Leo6Leo commented Feb 21, 2024

/lgtm

@knative-prow knative-prow bot added the lgtm Indicates that a PR is ready to be merged. label Feb 21, 2024
Copy link
Member

@pierDipi pierDipi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/approve

Copy link

knative-prow bot commented Feb 26, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Cali0707, matzew, pierDipi

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 [Cali0707,matzew,pierDipi]

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

@pierDipi
Copy link
Member

/test reconciler-tests-namespaced-broker

1 similar comment
@Cali0707
Copy link
Member Author

/test reconciler-tests-namespaced-broker

@Cali0707
Copy link
Member Author

/retest-required

@pierDipi
Copy link
Member

/test reconciler-tests

@knative-prow knative-prow bot merged commit f85af06 into knative-extensions:main Feb 27, 2024
36 of 37 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. area/control-plane area/data-plane area/test lgtm Indicates that a PR is ready to be merged. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
7 participants