Note that I think the most sustainable way to do this would be to use a DjangoStorage class to handle any file uploads in Kolibri - then it can be swapped out for a different class that supports the appropriate backend for the environment.

This is similar to #5698, except that this is for all non-content file operations - we have worked around content in remote settings by not having to import content at all, which seems better!

@rtibbles some thoughts & questions on this

Looks like we'll need to set up a BCK env so that we can authenticate to it w/ the google-cloud-storage lib.

I found this gcloud backend in a lib called django-storages (which is BSD-3-Clause fwiw in case we want to try to vendor the single backend to avoid WHL bloat?)

If I'm reading the DJango docs correctly and understanding well, the short list of things to do here are:

• Add the two dependencies to Kolibri
• Figure out how to setup the authentication business such that it will work w/ our BCK configuration (which, I believe, relies on the gcloud utility locally, but I imagine there is some automagical parts of this when connecting from one part of GCP to another?)
• On BCK, set the env var DEFAULT_FILE_STORAGE to that django-storages.storages.backends.gcloud module.
• Now BCK loads the GCloud file backend when that env-var is set and uses the default file system otherwise

Are there any other things I should be considering here w/ regard to how Kolibri works on BCK (cc @DXCanas @anguyen1234 ).

The main work is updating how we interact with files to use a DjangoStorage backend, currently we just deal with files on disk for the generated reports.

We don't need to add the google cloud backend to Kolibri's dependencies (I imagine that will cause a lot of bloat), so instead, we just need to make the default storage backend configurable. We can check that the right things are installed in the same way that we verify our Redis configuration too by trying to import the appropriate package: https://github.com/learningequality/kolibri/blob/develop/kolibri/utils/options.py#L287

The env var would that would be set on BCK then be mediated via the options.py machinery - it would presumably need more options, much like the Redis cache does, to configure the bucket, permissions, etc.

What Richard said. No gcloud utility. That’d be kinda insane. Because it’s running on google “hardware” it has ways of figuring out perms.

We typically rely on the default behavior to this point.

To learn more:
https://cloud.google.com/docs/authentication/provide-credentials-adc