mirror of https://github.com/knative/docs.git
Adding for blog post on improved event discovery (#5616)
* Adding DRAFT for blog post on improved event discovery Signed-off-by: Matthias Wessendorf <mwessend@redhat.com> * Fix typos * Add content to EventType auto create section * Fix typo * Add mention of channels and conclusion * Add links to slack channel and gh issues * adding link to new blog post Signed-off-by: Matthias Wessendorf <mwessend@redhat.com> --------- Signed-off-by: Matthias Wessendorf <mwessend@redhat.com> Co-authored-by: David Simansky <dsimansk@redhat.com>
This commit is contained in:
Matthias Wessendorf
GitHub
parent
70708b04cd
commit
49750e91eb
|
|
@ -45,6 +45,7 @@ nav:
|
|||
- releases/announcing-knative-v0-3-release.md
|
||||
- releases/announcing-knative-v0-2-release.md
|
||||
- Articles:
|
||||
- articles/new_event_discovery_features.md
|
||||
- articles/getting-started-blog-p1.md
|
||||
- articles/getting-started-blog-p0.md
|
||||
- articles/improved-ha-configuration.md
|
||||
|
|
|
|||
|
|
@ -0,0 +1,81 @@
|
|||
# Better Developer experience with improved event discovery in Knative
|
||||
|
||||
**Authors: David Simansky, Senior Software Engineer @ Red Hat, Matthias Weßendorf, Senior Principal Software Engineer @ Red Hat**
|
||||
|
||||
**Date: 2023-07-26**
|
||||
|
||||
_In this blog post you will learn about the new enhancements in Knative Eventing around event discovery._
|
||||
|
||||
Event discovery is an important part of event-driven applications, since it allows developers to better understand system dynamics and what events to consume. It does enable a more efficient and robust application design.
|
||||
|
||||
### Knative Event Type API enhancements
|
||||
|
||||
With the latest 1.11 release of Knative Eventing there were a few improvements related to improved Event discovery:
|
||||
|
||||
* `EventType`` API bumped to `v1beta2`
|
||||
* Making use of `reference`s to point to any Resource like Channels or Sinks, not just brokers
|
||||
* Enhance build-in Sources to create eventypes for any binding, not just brokers.
|
||||
* Automatic EvenType creation for Brokers
|
||||
|
||||
#### EventType API changes and version bump
|
||||
|
||||
After a couple of years being on version `v1beta1` the `EventType` API in Knative has changed and was bumped to `v1beta2`. The version bump did not come alone, it was combined with an overhaul for improved developer experience. It is now possible to point to any resource from an Event type object, instead of being only restricted to broker objects.
|
||||
|
||||
### Referencing other resources
|
||||
|
||||
The new version is marking the `broker` field as deprecated and it will be removed in a future release, instead we now have the `reference` field which takes any `KReference` API type, being able to point to any sink, channel or the broker as well. Let's take a look at the new `EventType` object:
|
||||
|
||||
```yaml
|
||||
apiVersion: eventing.knative.dev/v1beta2
|
||||
kind: EventType
|
||||
metadata:
|
||||
name: dev.knative.source.github.push-sss34cnb
|
||||
namespace: default
|
||||
spec:
|
||||
type: dev.knative.source.github.push
|
||||
source: https://github.com/knative/eventing
|
||||
reference:
|
||||
apiVersion: messaging.knative.dev/v1
|
||||
kind: InMemoryChannel
|
||||
name: testchannel
|
||||
```
|
||||
|
||||
The status was also changed, since we do just require the reference to be existing, instead of being also ready itself.
|
||||
|
||||
#### Duck Sources
|
||||
|
||||
The above enhancement did allow an additional change for the build-in sources, or any source that is compliant to the Sources Duck type. For instance until previous releases `EventType` objects where only created automatically when the source was pointing to a broker, because of the above restriction. Now those are created for any referenced sink, on the source, like:
|
||||
|
||||
```yaml
|
||||
apiVersion: sources.knative.dev/v1
|
||||
kind: PingSource
|
||||
metadata:
|
||||
name: ping-source-broker2
|
||||
spec:
|
||||
schedule: "*/1 * * * *"
|
||||
data: '{"message": "Hello world!"}'
|
||||
sink:
|
||||
ref:
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
name: log-receiver
|
||||
```
|
||||
|
||||
This results in an auto-created event type, like:
|
||||
|
||||
```bash
|
||||
k get eventtypes.eventing.knative.dev -A
|
||||
NAMESPACE NAME TYPE SOURCE SCHEMA REFERENCE NAME REFERENCE KIND DESCRIPTION READY REASON
|
||||
default 93774a924a741245a94313745d78e69f dev.knative.sources.ping /apis/v1/namespaces/default/pingsources/ping-source-broker2 log-receiver Service True
|
||||
```
|
||||
#### Auto Event Type creation
|
||||
|
||||
Furthermore to improve the experience with consumption and creation of `EventTypes`, there's a new experimental feature to automatically create `EventTypes` objects based on processed events on the broker ingress and in-memory channels. Instead of manually creating them as yaml manifests along the application code that talks to the Broker or Channel API. This behaviour can be enabled by feature flag `eventtype-auto-creation` in `config-features` ConfigMap. For futher details and examples please refer to [the documentation](https://knative.dev/docs/eventing/experimental-features/eventtype-auto-create/).
|
||||
|
||||
|
||||
|
||||
### Conclusion
|
||||
|
||||
This blog post introduced new features and improvements to `EventType` discoroverability. The main motivation is to harden the position of developer's insight into the event-driven applications to ease up the discovery and speed up development.
|
||||
|
||||
We look forward from the community to further enhance `EventType` API and discoverability. Please reach out on the CNCF Slack's [#knative-eventing](https://cloud-native.slack.com/archives/C04LMU33V1S) or GitHub [issues](https://github.com/knative/eventing/issues).
|
||||
Loading…
Reference in New Issue