Argo Events v1.7: There’s a new bus in town

The Argo team is excited to announce Argo Events v1.7! This release introduces:

• NATS Jetstream as an option for EventBus
• 3 Controllers Reduced to 1
• High Availability for Controller
• Support for Redis Streams Event Source
• Script Filtering for Sensors

NATS Jetstream

Currently Argo Events uses NATS Streaming (a.k.a. STAN) as its bus. But the NATS team is deprecating that in favor of their latest and greatest pub/sub bus: Jetstream.

We’ve incorporated the Jetstream bus as an additional option for the EventBus, so please try it out and let us know. For the time being, we’ll still support the NATS Streaming option too. The NATS will continue to support NATS Streaming for critical bug fixes until 6/2023.

The Jetstream Bus can be configured similar to the NATS Streaming bus:

apiVersion: argoproj.io/v1alpha1
kind: EventBus
metadata:
  name: default
spec:
  jetstream:
    version: 2.8.1  

Similar to NATS Streaming, this will start up a StatefulSet with 3 replicas by default, but you can specify more if you like.

The version number shown above describes the version of the NATS Server. The versions we support can be found by running:

kubectl describe configmap argo-events-controller-config

This includes version 2.8.1 (plus 2.8.1-alpine). If we find some need to use a newer version we’ll add that as an option. Also, please feel free to update the argo-events-controller-config to try out newer versions.

See here for the full list of configurable fields.

Reliability

Like with NATS Streaming, while we we aim to reduce duplicate messages, messages can be duplicated if a pod crashes mid-message: therefore, we only promise “at least once”.

What differs from our use of NATS Streaming in Argo Events?

For the most part, you should expect everything to behave the way you’ve come to expect with the NATS Streaming bus. Here are some notes about what is different:

No exotic option

With NATS Streaming we offer an option we call “exotic”, meaning the user can supply their own NATS Streaming bus. We found that wasn’t being used, so for Jetstream we’re currently not supporting that option.

Key/Value store

Jetstream offers a key/value store database, so we’re taking advantage of it for Sensor Triggers that use conditional expressions containing an &&, like:

triggers:
    - template:
        conditions: "my-kafka-event && my-calendar-event"
        name: trigger-1

This type of condition requires you to store the part of the condition that has been received so far until the rest arrives. With NATS Streaming, we don’t have a database to store this information persistently, so instead we purposely don’t ack the message — forcing NATS to keep resending it — until the rest of the condition arrives.

With Jetstream, we can cut down on this extra processing by storing the partial condition instead.

Duplicate Dependencies Restriction Removed

With the new implementation of message processing for Jetstream, we’ve been able to remove the restriction that a Sensor can’t have two dependencies which reference the same event. So, this is allowed:

spec:
  dependencies:
    - name: dep01
      eventSourceName: webhook
      eventName: example
      filters:
        data:
          - path: body.value
            type: number
            comparator: "<"
            value:
              - "20.0"
    - name: dep02
      eventSourceName: webhook
      eventName: example
      filters:
        data:
          - path: body.value
            type: number
            comparator: ">"
            value:
              - "50.0"

Security

Unliked with NATS Streaming, we have incorporated both encryption at rest and encryption in transit. TLS v1.3 is incorporated into all communication between the NATS Jetstream bus and its clients, as well as between the NATS cluster nodes. The primary motivation for TLS was to encrypt the client’s password and prevent bad actors from connecting. This is all happening behind the scenes, so no additional configuration is required.

Documentation

For more information about the new Jetstream bus in Argo Events please see our documentation here.

3 Controllers Reduced to 1!

To reduce code and make it easier to maintain, we reduced the 3 Controllers for EventBus, EventSource, and Sensor down to a single controller called “controller-manager”. Before you upgrade, you need to delete the old deployments:

kubectl -n argo-events delete deploy eventbus-controller
kubectl -n argo-events delete deploy eventsource-controller
kubectl -n argo-events delete deploy sensor-controller

High Availability for the Controller

Our new Controller can be replicated for High Availability:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: controller-manager
  namespace: argo-events
spec:
  replicas: 3

The replicas are in an Active-Standby configuration and are using Kubernetes’ leader election. (Thanks @davidcollom!)

Redis Streams Event Source

You can now configure Redis Streams as your Event Source (Thanks @BulkBeing!). See details here. Redis Streams is sometimes described as a lightweight alternative to Kafka. Multiple streams from a single database can be configured per Event Source. With this, we now support 21 different types of Event Sources.

Script Filtering

A new option exists for adding Filters for your sensors (Thanks @VaibhavPage). If you prefer to use Lua, a filter that looks like this:

filters:
  dataLogicalOperator: "and"
  data:
    - path: "a"
      type: "string"
      value: 
        - "hello"
    - path: "b.d"
      type: "string"
      value:
        - "goodbye"

could be condensed down to this instead:

filters:   
  script: |-     
    if event.body.a == "hello" and event.body.b.d == "goodbye" then 
    return true else return false end

Try the New Release

For installation and more detail about the release, check our release notes.

Thank You!

Thanks to everyone who made contributions to the new release! And special thanks to everyone in the community who helped by testing, raising issues, and providing feedback. Keep it coming!

@davidcollom
@jcantosz
@lsl-msft
@juliev0
@alexec
@whynowy
@BulkBeing
@VaibhavPage
@daniel-codefresh
@lacarvalho91
@descrepes
@tvalasek
@blkperl
@JPZ13