Skip to content

Argo Events components: CAPA practice questions

The Argo Events architecture has four parts: the EventSource, the EventBus, the Sensor and the Trigger. Following one event through them explains most of the design.

By Ibrahim Yesilay · Published · Updated

Independent community practice, not affiliated with or endorsed by CNCF or The Linux Foundation.

What Argo Events components covers in CAPA

The Argo Events architecture has four parts: the EventSource, the EventBus, the Sensor and the Trigger. Following one event through them explains most of the design.

An EventSource holds the configuration needed to consume events from a system such as a webhook, a message queue, a bucket or a calendar. It turns each event into a CloudEvent and publishes it to the EventBus. One EventSource can define several named events of the same type, for example two webhook endpoints, and a Sensor refers to an event by the eventSourceName and eventName pair.

The EventBus is the transport layer between EventSources and Sensors: EventSources publish to it and Sensors subscribe to it. Its three implementations are NATS Streaming, which is deprecated, Jetstream and Kafka. The common practice is one EventBus named default per namespace; an EventSource or Sensor that should use a different one sets eventBusName.

A Sensor declares event dependencies as its inputs and triggers as its outputs, and acts as a dependency manager. Each dependency names an event and can carry filters that decide whether an event is valid: expr, data, script, context and time filters, evaluated in the order expr, data, context, time, and combined with and or or through filtersLogicalOperator. Each trigger can carry conditions, a boolean expression over dependency names such as (dep01 || dep02) && dep03; without conditions, a trigger waits for all of its dependencies. A conditions reset, for example by a cron time, clears dependencies that were only partly satisfied.

A Trigger is the resource or workload the Sensor executes once its conditions hold. The types include Argo Workflows, Argo Rollouts, any Kubernetes object, HTTP requests for serverless platforms, AWS Lambda, Apache OpenWhisk, Kafka and NATS messages, Azure Event Hubs, Slack and a log trigger for debugging. Parameters copy values from the event into the trigger's resource, naming the dependency, a dataKey or contextKey to read and a dest path to write, with dataKey winning if both are set. A retryStrategy retries a failed trigger, and some trigger types, such as Argo Workflows and Kubernetes objects, accept a policy that decides whether the created resource counts as a success.

For high availability, an EventSource or Sensor can set spec.replicas above 1 rather than being scaled by hand. Sensors and most EventSources then run active-passive with leader election, while some EventSources, such as webhooks, SNS and SQS, run active-active.

Key points

  • EventSources publish CloudEvents to the EventBus; Sensors subscribe and fire triggers.
  • EventBus implementations are NATS Streaming (deprecated), Jetstream and Kafka.
  • A trigger without conditions waits for all of the Sensor's dependencies.
  • High availability is set with spec.replicas; never scale the Deployments by hand.

Three sample questions

13 CAPA questions on Argo Events components, 13 with explanations. How practice works

Question 1

What is the correct way to define a webhook event source? 
apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
  name: webhook
spec:
  webhook:
    example:
      port: "12000"
      endpoint: /webhook
  1. A.The configuration is correct
  2. B.webhook should be webhooks
  3. C.Port should be an integer
  4. D.Endpoint must start with /api

Correct answer: A

The EventSource spec holds a map of webhook event sources, each with a port (a string in the API) and an endpoint. The webhook docs show the event source listening on a port such as 12000 and an endpoint such as /example. Why the other options are wrong. "webhook should be webhooks": the spec field is webhook, a map of named webhook event sources, not webhooks. "Port should be an integer": the API reference types webhook port as a string, so "12000" is the right form. "Endpoint must start with /api": endpoint is a plain REST path with no required /api prefix; the docs' own example uses /example.

Sources: Argo Events docs: Webhook, Argo Events docs: API Reference

Question 2

What does the following Sensor dependency configuration mean? 
dependencies:
- name: webhook-dep
  eventSourceName: webhook
  eventName: example
- name: calendar-dep
  eventSourceName: calendar
  eventName: hourly
  1. A.Invalid configuration
  2. B.Triggers only when both events occur
  3. C.Triggers when either event occurs
  4. D.Triggers when webhook fires, then waits for calendar

Correct answer: B

Without a conditions expression on the trigger, a Sensor fires its triggers only when all listed dependencies have been resolved, here one webhook event and one calendar event. Why the other options are wrong. "Invalid configuration": two dependencies with names, eventSourceName and eventName are valid. "Triggers when either event occurs": OR logic needs a trigger condition such as conditions: "webhook-dep || calendar-dep". "Triggers when webhook fires, then waits for calendar": dependencies have no order; both must arrive.

Sources: Argo Events docs: Trigger Conditions, Argo Events docs: Sensor

Question 3

Which of the following is NOT a valid EventSource type in Argo Events?
  1. A.PostgreSQL
  2. B.Redis (subscribing to a Redis publisher)
  3. C.GitHub (repository webhook events)
  4. D.Apache Kafka (consuming messages from topics)

Correct answer: A

The Argo Events documentation has setup pages for event sources such as Kafka, Redis, GitHub, webhooks, calendar and cloud queues, and no PostgreSQL event source appears. Why the other options are wrong. "Redis (subscribing to a Redis publisher)": the Redis event source subscribes to a Redis publisher. "GitHub (repository webhook events)": GitHub has its own event source page. "Apache Kafka (consuming messages from topics)": the Kafka event source listens to messages on topics.

Sources: Argo Events docs: Argo Events, Argo Events docs: Redis EventSource, Argo Events docs: Kafka EventSource

Practice this topic

Focus mode keeps every question on Argo Events components until you leave it. 10 free guest answers, then a free account; no credit card.

Or open CAPA practice across all topics.

Sources

The explanation above was checked against these official documents.