rh-event-flow/eventflow

Simple dataflow for CloudEvents

eventflow's Issues

Convert demo to more standard components

Motivation:
Leave as many components as-is and see how far we can get to be able to give the same demo but using purely Knative custom resources

• Source: https://gist.github.com/matzew/77afd1066fdbf75ffb317132f224f8ec
• Subscriber could be normal web servers, like VErt.x or Microprofile

Support data-source with multiple topics

It would be nice if a data-source could submit data to a number of topics, leveraging only one Target to send the data out of the processor

differentiate between types

It would be good to differentiate between types. Currently all is a CloudEventComponent, but it would be nice to have them being more explicit:

• Source
• Sink
• Processor

Convert DeploymentConfigs to Deployments

In order to only use the k8s java client, it's required that we move the deploymentConfigs to pure k8s deployments.

Ideally we are leveraging the latest versions of the k8s-client (4.0.4) and the k8s-model (3.0.3)

Convert JSP files to actual REST endpoints

Let's remove the usage of JSP, and bring things to proper Java, using JAX-RS endpoints

Developer Experience for deploy

Big question:

• how does Developer Experience look compared to what Reactive Messaging currently does?

There is existing code to "deploy" Reactive Messaging apps but do we extend this to be able to deploy our application components into OpenShift.

Refactoring

Some refactoring tasks are going to happen:

• rename packages (io.streamzi.eventflow.***)
• change modules
  • eventflow-common
  • eventflow-model
  • eventflow-operator (now watcher)
  • eventflow-skd (new, extracted from model)
  • eventflow-runtime (now container)
  • eventflow-ui (now `manager)
• release
• update the archetype + samples
• change the download url to the CRD files in APB after refactoring

Each root bullet-point will be a separate PR

Apache Kafka 2.0.0 Client usage

With Strimzi 0.7+ we have Apache Kafka inside our cloud service.

The EventFlow currently uses the older 1.0.0 version, and should be updated to 2.0.0

Operator needs to emit different custom resources

generating Knative resources, like:

• Subscriptions
• Channels, …

Rebase existing code onto Knative primitives

• EventFlow Microservices -> Serving applications
• EventFlow connections -> Channels

• API to retrieve existing Serving applications
• Operator to create Channels instead of Topics
• Operator to create Subscriptions instead of Environment Variable configs
• Work out strategy for describing Serving application outputs

Move to HTTP instead of Apache Kafka

Use Reactive Messaging / CloudEvents where possible. At the moment can't have processors/sinks that use Reactive Messaging but sources will work

404 for sample processors

Hi

On your readme, you have the following:

A number of stream processors are available here!

But the link is broken.

remove globalSettings

From the API we need to remove the flow globalSettings, since they are unused!