Linode Object Storage Setup

[kurtbruns]

This guide has the steps for setting up Linode object storage.

If you would like me to setup the bucket I'll need an login with a payment method. Otherwise, I think the general steps are:

1. Create a bucket and upload a test file.
2. Allow Public Read Access for objects via Cloud Manager. See this doc for full details.
3. Install the Linode CLI for programmatic upload/download/delete abilities.
4. Generate access tokens for team members to allow programmatic access.

[vincerubinetti]

Is programmatic access really necessary here? I feel like we just need a simple web interface where you can drag and drop files. Hell, if services like Dropbox allowed cross-origin access, I would've said we should use that.

It seems like Grant already has AWS set up and working? And I'd imagine the AWS and Linode pricing are pretty close to be competitive. Seems like we should just go ahead with AWS if it's simple enough to use, acceptably priced, and already set up.

[kurtbruns]

I think programmatic access (Linode CLI or AWS CLI) would make for a really nice workflow and allow for consistent versioning of the site. For example, graphics can be created, modified and viewed on a local branch without interacting with the bucket. Then, when it comes time to deploy the changes to the live site, a command like this can be run:

git status --porcelain

Which returns the list of modified and added files.

M  images/test/figure-4.14-4.57.png
A  images/test/figure-4.18.png

Using this list, the CLI tool would allow us to programmatically sync the state of the bucket with the current commit.

Two notes: (1) When viewing pull requests on Vercel or similar, it probably makes sense to have the preview version of the site contain the assets for the site, rather than interact with the bucket. (2) For a real deploy, we would compare the last deployed hash with the current commit hash to get the list of new/changed files.

[kurtbruns]

As for AWS vs. Linode. We still have to set up a bucket policy and share access to the bucket, which I think is where the bulk of the work lies. The reason I am pushing for Linode is that the quality of their services, documentation and support is great -- which I think will save us time and improve our quality of life. At the end of the day, I am happy and excited to work with either tool.

In regards to the overall bloggification process, I think it would be very useful to round-trip the markdownification process fairly soon, even today if possible.