Skip to content

Sync IVS Real-Time recording configuration#1

Open
stevethomas wants to merge 2 commits into
mainfrom
seth/lpx-560-ivs-recording
Open

Sync IVS Real-Time recording configuration#1
stevethomas wants to merge 2 commits into
mainfrom
seth/lpx-560-ivs-recording

Conversation

@stevethomas
Copy link
Copy Markdown
Member

What problems are you solving?

Adds a sync:recording command that provisions the S3 + IVS Real-Time resources needed for composite recording of IVS Real-Time stages to S3.

Duplicated from codinglabsau/yolo#21 (authored by @SethSharp) so this work can ship on yolo-alpha while LP is still mid-migration. Namespace + pint sweeps applied to match the yolo-alpha codebase; otherwise functionally identical to #21.

Is there anything the reviewer needs to know to deploy this?

1. yolo.yml

aws:
  ivs:
    recording:
      real_time: true

Omitting recording skips all recording steps — no change for existing deployments.

2. Sync

yolo-alpha sync:recording production

After running, three values are printed for the app's .env:

AWS_IVS_REALTIME_RECORDINGS_BUCKET=yolo-{env}-{app}-ivs-realtime-recordings
AWS_IVS_STORAGE_CONFIGURATION_ARN=arn:aws:ivs:...
AWS_IVS_ENCODER_CONFIGURATION_ARN=arn:aws:ivs:...

3. IAM permissions for the user running yolo-alpha

Policy Type Why
AmazonS3FullAccess AWS managed Create recording bucket + bucket policy/ownership
IVSFullAccess AWS managed Create StorageConfiguration and EncoderConfiguration

What sync:recording provisions

Step What it creates
SyncIvsRealtimeRecordingBucketStep S3 bucket; policy allows ivs-composite.{aws.region}.amazonaws.com to write with bucket-owner-full-control, and grants the MediaConvert role read access. Ownership set to BucketOwnerPreferred
SyncIvsStorageConfigurationStep IVS Real-Time StorageConfiguration pointing at that bucket
SyncIvsEncoderConfigurationStep IVS Real-Time EncoderConfiguration (720p30 @ 2.5 Mbps)

All run in the single aws.region. Each step is idempotent (returns SYNCED when the resource already exists) and skips gracefully when aws.ivs.recording.real_time is not set.

Recording format

IVS composite recording outputs TS-based HLS — directly compatible with the existing MediaConvert pipeline, no FFmpeg/pre-processing step required.

Notes

  • Bucket name auto-generated via Helpers::keyedResourceName() to avoid global S3 name collisions
  • BucketOwnerPreferred ownership is required because IVS writes objects with the bucket-owner-full-control ACL
  • No IAM roles are provisioned for recording (sync:iam unchanged)

stevethomas and others added 2 commits May 19, 2026 11:42
Adds a `sync:recording` command that provisions the S3 + IVS Real-Time
resources needed for composite recording of IVS Real-Time stages to S3.

Originally authored by Seth Sharp against codinglabsau/yolo#21 (targeted
at the 1.x branch). Duplicated here so it can ship on yolo-alpha while
LP is still mid-migration. Namespace + pint sweeps applied to match the
yolo-alpha codebase.

### yolo.yml

```yaml
aws:
  ivs:
    recording:
      real_time: true
```

Omitting `recording` skips all recording steps — no change for existing
deployments.

### sync

```bash
yolo-alpha sync:recording production
```

After running, three values are printed for the app's .env:

- AWS_IVS_REALTIME_RECORDINGS_BUCKET
- AWS_IVS_STORAGE_CONFIGURATION_ARN
- AWS_IVS_ENCODER_CONFIGURATION_ARN

### What sync:recording provisions

| Step | What it creates |
|---|---|
| SyncIvsRealtimeRecordingBucketStep | S3 bucket; policy allows `ivs-composite.{aws.region}.amazonaws.com` to write with `bucket-owner-full-control`, grants MediaConvert role read access. Ownership set to BucketOwnerPreferred |
| SyncIvsStorageConfigurationStep | IVS Real-Time StorageConfiguration pointing at that bucket |
| SyncIvsEncoderConfigurationStep | IVS Real-Time EncoderConfiguration (720p30 @ 2.5 Mbps) |

All run in the single aws.region. Each step is idempotent (returns
SYNCED when the resource already exists) and skips gracefully when
aws.ivs.recording.real_time is not set.

### IAM permissions for the user running yolo-alpha

| Policy | Why |
|---|---|
| AmazonS3FullAccess | Create recording bucket + bucket policy/ownership |
| IVSFullAccess | Create StorageConfiguration and EncoderConfiguration |

### Notes

- Bucket name auto-generated via Helpers::keyedResourceName() to avoid
  global S3 name collisions
- BucketOwnerPreferred ownership is required because IVS writes objects
  with the bucket-owner-full-control ACL
- No IAM roles are provisioned for recording (sync:iam unchanged)
- IVS composite recording outputs TS-based HLS — directly compatible
  with the existing MediaConvert pipeline, no FFmpeg/pre-processing step
  required

Co-Authored-By: Seth Sharp <58869086+SethSharp@users.noreply.github.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
All parallel pest processes shared the same /tmp/yolo-test directory
and the same yolo.yml inside it. Process A wrote its manifest, process
B overwrote it, process A read the wrong file — surfacing as
intermittent IntegrityCheck / TypeError failures.

Pre-existing latent bug; got unlucky with parallel ordering as
ManifestTest grew, exposing the race. Tests still passed
deterministically when run serially (which is why the alpha extraction
+ pint sweep CI runs went green).

Use TEST_TOKEN (paratest sets this per worker) with getmypid() fallback
to give each process its own temp dir.

Verified: 5 consecutive --parallel --processes=4 runs all 54/54.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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