What if object storage was required?

How would you, as an Peertube admin, react if object storage was required to host a a Peertube instance? If you’re not using object storage today, it’s possible to run minio as a docker container and there’s also Backblaze which is a cheap object storage provider in the cloud.

By enforcing object storage usage we’d reduce a lot of complexity in the code. To help users get a up and running we could provide a production ready docker-compose.yml with nginx, minio and Peertube.

@Chocobozzz what’s your thoughts about this?

I don’t want to use object storage.
This adds a lot of complexity on simple instances.

For example, I have clients who have instance with only a few videos. There is absolutely no good reason to use object storage for this.

Also, i make the learning curve more complex for admins. We already see a lot of admins that found it complicated to setup Peertube, because it requires to know various concepts (nginx, nodeJS, redis, postgres, …). Adding object storage will make it way more complicated.

It also make complicated various admin sys operation: backups, data migration, restore data after a bad manipulation, …

With object storage, it is more complicated to see the exact state of your storage.
Object storage can also come with permission issues.

Object storage increase the attack surface (compared to having static files served by nginx).

Object storage make some upgrades operation more difficult if we want to prevent data lost (we must ensure that all services are properly stopped, with no waiting operation…).

I can find other reasons why I don’t want to use object storage.

2 Likes

Thanks for your answer.

For example, I have clients who have instance with only a few videos. There is absolutely no good reason to use object storage for this.

The good reason would be to simplify Peertube code base in order to have fewer bugs and deliver new features in faster pace.

Also, i make the learning curve more complex for admins. We already see a lot of admins that found it complicated to setup Peertube, because it requires to know various concepts (nginx, nodeJS, redis, postgres, …). Adding object storage will make it way more complicated.

docker-compose up -d can spin up nginx, peertube, peertube runner, redis, postgres and minio, I guess it can’t be easier? If the admin has issues with this, he can get help from thousands (millions?) of other people using docker, instead of getting help from the Peertube community.

No more issues with functionality that doesn’t work due to different versions of node, ffmpeg or other environmental behavior. Debugging and helping admins would also be easier since docker compose logs > debug.logs would provide a chronological log from all services.

It also make complicated various admin sys operation: backups, data migration, restore data after a bad manipulation, …

Database backups can be done as it’s done today. If the aim is to have all user files (videos, thumbnails, captions, etc) on object storage, then a migration should be easier. Googling migrate minio will result in more and more accurate hits than migrate peertube. Migrating minio can also be done without downtime.

With object storage, it is more complicated to see the exact state of your storage.

I think most admins think it’s pretty the same, or even easier, to watch a web page instead of connect with ssh/ftp to a server.

Object storage can also come with permission issues.

Not if we provide minio in docker preconfigured. Of course admins should be able to change the config, and then they can get permission issues, but that’s how it is today as well.

Object storage make some upgrades operation more difficult if we want to prevent data lost (we must ensure that all services are properly stopped, with no waiting operation…).

I don’t see how this differ from non-object storage setup. But I agree this should be simplified by implementing Ability to put site into maintenance mode · Issue #1230 · Chocobozzz/PeerTube · GitHub

If object storage requirement would be combined with docker requirement/recommendation I think the overall admin task would be simplified. It seems I’m not alone appreciating docker:

Docker users have elevated this tool to most-admired (78%) this year along with being most-desired for the second year in a row.
Technology | 2024 Stack Overflow Developer Survey

S3 storage is another service with its own quirks. If well documented, can be a great alternative to hosting files locally. Not everyone would want to host their video files locally. I can think of few cases why someone may want to host their instance on a small machine, and offload hosting to a separate machine. Putting minio in same docker compose file is a good way to simplify if a person wants to host their files locally, but that may not be desirable in many cases.

I agree with all your points except that you suggest setting up an instance is easy due to how short the command that starts the instance is.

At least that is what I understood.

It is rarely the commands that need to be run is the thing causes confusion. In find terminal commands for setup, start, stop and updating the server software to be the best documented part of a documentation. But why and how different server softwares integrate or communicate with each other are not that well documented. And because we almost always end up with some kind of deviation from the documentation, what to write in certain field of the docker compose file can cause confusion.

When I was setting up my instance, I wanted to use my already existing mail server running on another machine. I would like to think myself as an experienced docker user, but setting up SMTP connection for my instance was still confusing. After trying and failing to set up SMTP with few different configurations, I gave up on using emails. None of the new users were getting email confirmation emails. Today I received an email from my instance’s email address about a new version of Peertube becoming available. I was surprised to find that it is working. And I still am clueless about why it works, and why it wasn’t working.