Skip to content

Migration for instance level audit event headers

Hitesh Raghuvanshi requested to merge 404560-streaming-headers into master

What does this MR do and why?

We have added instance level external audit event destinations as part of issue #335175 (closed). Now we need to add streaming headers for these destinations which will allow users to add their custom headers to be sent when we stream audit events to the added destinations. These headers are similar to the headers being sent for group level audit events being streamed to external destinations.

This MR does following:

  1. Adds a migration for creating table instance_audit_events_streaming_headers.
  2. Adds a corresponding model InstanceHeader for the table.
  3. Since some things are common between Header and InstanceHeader, we have added a concern StreamableHeader for having common validations and methods.

Note: GraphQL APIs for performing CRUD operations will be added in a subsequent MR.

Migration details:

###up

RAILS_ENV=development bin/rails db:migrate:up:main VERSION=20230516175449

main: == [advisory_lock_connection] object_id: 278780, pg_backend_pid: 4815
main: == 20230516175449 CreateInstanceAuditEventsStreamingHeaders: migrating ========
main: -- create_table(:instance_audit_events_streaming_headers)
main: -- quote_column_name(:key)
main:    -> 0.0000s
main: -- quote_column_name(:value)
main:    -> 0.0000s
main:    -> 0.0091s
main: == 20230516175449 CreateInstanceAuditEventsStreamingHeaders: migrated (0.1421s)

###down

RAILS_ENV=development bin/rails db:migrate:down:main VERSION=20230516175449
main: == [advisory_lock_connection] object_id: 278820, pg_backend_pid: 5256
main: == 20230516175449 CreateInstanceAuditEventsStreamingHeaders: reverting ========
main: -- drop_table(:instance_audit_events_streaming_headers)
main:    -> 0.0028s
main: == 20230516175449 CreateInstanceAuditEventsStreamingHeaders: reverted (0.0098s)

main: == [advisory_lock_connection] object_id: 278820, pg_backend_pid: 5256

How to set up and validate locally

Since there are no functional changes in this MR, there is nothing to validate apart from running the migration and checking the model in the rails console. There will be subsequent MRs related to APIs around the new table/model added.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #404560 (closed)

Edited by Hitesh Raghuvanshi

Merge request reports