Skip to content

Conversation

@gabriel-samfira
Copy link
Member

@gabriel-samfira gabriel-samfira commented Jul 4, 2024

This change adds a new websocket endpoint for database events. The events endpoint allows clients to stream events as they happen in GARM. Events are defined as a structure containning the event type (create, update, delete), the database entity involved (instances, pools, repos, etc) and the payload consisting of the object involved in the event. The payload translates to the types normally returned by the API and can be deserialized as one of the types present in the params package.

The events endpoint is a websocket endpoint and it accepts filters as a json encoded Options{} type defined here. This json is send over the websocket connection. The filters allows the user to specify which entities are of interest, and which operations should be returned. For example, you may be interested in changes made to pools or runners, in which case you could create a filter that only returns update operations for pools. Or update and delete operations.

The filters can be defined as:

{
  "filters": [
    {
      "entity_type": "instance",
      "operations": ["update", "delete"]
    },
    {
      "entity_type": "pool"
    },
  ],
  "send_everything": false
}

This would return only update and delete events for instances and all events for pools. Alternatively you can ask GARM to send you everything:

{
  "send_everything": true
}

If no ofilters are set, all events are ignored and nothing is sent over the connection.

To help view these events, a new command was added to the garm-cli command:

garm-cli debug-events \
    --filters='{"send_everything": false, "filters": [{"entity_type": "instance"}, {"entity_type": "pool"}]}'

Which will return events for pools and instances. Here is an example of the command in action:

asciicast

More complex filters may be added in the future.

A few notes on authentication. To authenticate against the websocket endpoint, you'll still use the JWT bearer token you normally use. The websocket handler will then start a timer that will expire at the same time as your token. When that happens, your connection will be terminated.

Also, if the user is updated and either is disabled, the password changes or is removed, the connection will be terminated.

@gabriel-samfira gabriel-samfira force-pushed the add-event-stream branch 3 times, most recently from 9e8de5b to 4dd4151 Compare July 4, 2024 14:39
The websocket client and hub interaction has been simplified a bit.
The hub now acts only as a tee writer to the various clients that
register. Clients must register and unregister explicitly. The hub
is no longer passed in to the client.

Websocket clients now watch for password changes or jwt token expiration
times. Clients are disconnected if auth token expires or if the password
is changed.

Various aditional safety checks have been added.

Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
This change adds a new websocket endpoint for database events. The events
endpoint allows clients to stream events as they happen in GARM. Events
are defined as a structure containning the event type (create, update, delete),
the database entity involved (instances, pools, repos, etc) and the payload
consisting of the object involved in the event. The payload translates
to the types normally returned by the API and can be deserialized as one
of the types present in the params package.

The events endpoint is a websocket endpoint and it accepts filters as
a simple json send over the websocket connection. The filters allows the
user to specify which entities are of interest, and which operations should
be returned. For example, you may be interested in changes made to pools
or runners, in which case you could create a filter that only returns
update operations for pools. Or update and delete operations.

The filters can be defined as:

{
  "filters": [
    {
      "entity_type": "instance",
      "operations": ["update", "delete"]
    },
    {
      "entity_type": "pool"
    },
  ],
  "send_everything": false
}

This would return only update and delete events for instances and all events
for pools. Alternatively you can ask GARM to send you everything:

{
  "send_everything": true
}

Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
Improper use of time.After can lead to memory leaks if the timer never
gets a chance to fire.

Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
@gabriel-samfira
Copy link
Member Author

merging this as is. We can iterate later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant