Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] PutUploader #650

Open
Nitschi opened this issue Apr 11, 2024 · 4 comments
Open

[FEATURE] PutUploader #650

Nitschi opened this issue Apr 11, 2024 · 4 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@Nitschi
Copy link

Nitschi commented Apr 11, 2024

Is your feature request related to a problem? Please describe.

In our organization, due to privacy requirements, we need to keep our video recordings on-premise. Currently, LiveKit Egress supports uploading files to cloud storage solutions like S3, GCP, and others very conveniently. However, this does not meet our compliance needs, as we need to ensure that all recordings are stored within our own infrastructure without passing through third-party cloud providers.

Describe the solution you'd like

We propose the addition of a PutUploader to the LiveKit Egress service. This uploader would use HTTP PUT requests to upload video recordings directly to our on-premise storage solutions or any HTTP server that we configure. This feature would allow organizations with self-hosted recording setups to easily store them on-premise.

The PutUploader should be configurable through the Egress service's YAML configuration file, allowing users to specify the endpoint URL, authentication credentials, and any other relevant HTTP headers required by the receiving server. Additionally, it would be beneficial to support retries and configurable timeout settings to ensure robustness in network variability scenarios.

Describe alternatives you've considered

As an alternative, we have considered using the existing file output mechanism to first save recordings locally and then manually upload them to our on-premise servers based on a small script that checks for new files on a regular basis. However, this approach introduces additional complexity and delay in our workflow, as it requires a separate process to monitor, upload, and verify the integrity of the recordings post-egress.

Another alternative is to modify the source code of LiveKit Egress ourselves to include this feature. However, we believe that contributing this feature back to the community would be beneficial for many organizations with similar privacy and compliance requirements.

Additional context

We are willing to contribute to the development of this feature and look forward to your feedback on the proposal.

@Nitschi Nitschi added enhancement New feature or request help wanted Extra attention is needed labels Apr 11, 2024
@serhiynovos
Copy link

Instead of cloud S3 storage on premise solutions also can be used any s3 compatible storage like minio. Other solution I see it's just mount to egress volume like NAS so recordings can be stored on prem on remote server with no egress code changes. Or event to have sidecar container which will be watching folder changes and upload to remote server

@Nitschi
Copy link
Author

Nitschi commented Apr 25, 2024

@serhiynovos, thank you for your suggestions. While integrating an S3-compatible storage solution like MinIO or utilizing NAS for on-prem storage could work, these approaches would introduce significant changes to our existing infrastructure and operational workflows. Our current ecosystem uses an ASP.NET backend for handling various types of recordings, and we aim to maintain consistency in how video recordings are managed and stored.

Implementing a sidecar container to monitor and upload files would require the development of a new service for handling webhook messages, which increases configuration complexity, CI, maintaning work etc.

The idea of deploying a script that continuously monitors a directory for new files and uploads them might seem like a simpler workaround. However, considering the sophistication of LiveKit's existing upload mechanisms, this solution feels more like a temporary patch rather than a robust, long-term strategy.

Incorporating HTTP PUT (or POST) support directly within LiveKit as an uploader option would offer a consistent and maintenance-friendly solution. It aligns with many existing backend services and simplifies the configuration process, eliminating the need for additional components or significant infrastructural adjustments. This feature would not only benefit our organization but also support other users in the community with similar requirements for privacy, compliance, and on-premises data handling.

As a first proof of concept my colleague has written a standalone uploader that works well, even for bigger file-sizes (if the backend can handle it): goPutUploader

Would integrating something like this be an option?

@serhiynovos
Copy link

@Nitschi Yes, it could be a cool feature to have file uploader. Here I see one complexity it's how to deal with upload API as it can have different auth mechanisms and egress should support all of them to cover all organisations needs.

But in any case let's wait for Livekit team answer, they have to know much better 😊

@Nitschi
Copy link
Author

Nitschi commented Apr 25, 2024

My guess would be, that 90% of users would be happy with a simple token/secret-based approach.
For our case we could use any of the many possibilites that libraries like ASP.NET supports, so less flexibility is needed on livekits side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants