Using the name 'rustic' as part of a third-party repo name?

[philipmw]

Hello, @aawsome . As you know, I created warmup-s3-archives-cdk as a proof-of-concept CDK application that makes it easier to adopt warmup-s3-archives for warming up rustic cold repositories in Glacier. Since then, it became more than a proof of concept -- I've been turning it into a one-step adoption of cold storage backups using rustic.

I've long had a dilemma about how generic versus rustic-specific to make warmup-s3-archives-cdk. The warmup-s3-archives program is completely generic, thanks to rustic's plugin architecture. For this CDK application to be completely generic also, it needs only one S3 bucket. However, I've always made the CDK application create two, to make it easier for people to adopt rustic in one step. Otherwise they'd need to create a second bucket separately, update the IAM policies to allow access to this bucket, etc. As another rusticism, I recently restricted IAM permissions to make backups append-only; this makes the infrastructure less generic further.

So, the CDK application is growing more rustic-specific. I believe this is customer-obsessed and I welcome it. I don't want to straddle the specific/generic fence anymore; I want to fully lean into the rustic backups use-case. But then I am no longer happy with the warmup-s3-archives-cdk repo's name -- it made sense in my head in the context of the warmup feature proof-of-concept, but it makes no sense if I think of this CDK application as a landing zone for customers who want a simple way to set up AWS infrastructure for rustic backups. Now I think a more appropriate name would be something like rustic-backup-to-glacier-infra.

I want to check with you whether you'd be ok with my CDK application repo having this name, with "rustic" being part of it?

[aawsome]

Hi @philipmw

There is no trademark for the name "rustic". So, yes use it as you wish. If you consider to put the repo under the rustic-rs organization, let me know, then we can arrange this.

[philipmw]

That sounds good. I am envisioning a separate repository for each infrastructure-as-a-service integration for hot and cold backups in different clouds.

I already have a CDK application for cold storage in AWS that I could migrate over, and I can make a separate CDK application for hot storage in AWS.

Shall we do that under the rustic-rs org?

[Sparticuz]

I've been wanting to migrate off of the legacy Glacier to S3 Glacier (because I switched from Synology Photos to immich) and ran into rustic while searching for a solution that did native hot/cold, which then ran into @philipmw's repo. I'm very interested in this and would be interested in starting my repo from scratch with this. (I had just started setting up warmup-s3-archives-cdk when I found this discussion)

[philipmw]

@Sparticuz , you can go ahead and set up warmup-s3-archives-cdk now and give your feedback. I believe we can move it to be under the rustic-rs org in a backward-compatible way, so you wouldn't need to tear it down.

@aawsome , will you give me permissions to do the migration into the rustic-rs org?

[aawsome]

@philipmw Sorry for the delay. I would propose to create a generic repo for aws-support, e.g. rustic-rs/rustic-aws where you (or others) could place AWS-specific infrastructure-as-code/scripts/config solutions.

Are you fine with this name? I would make you a maintainer for this repo.

(We have something similar already for rustic-helm)

[aawsome]

https://github.com/rustic-rs/rustic-aws

[philipmw]

I moved https://gitlab.com/philipmw/warmup-s3-archives-cdk to https://github.com/rustic-rs/rustic-aws/tree/main/glacier-cold-storage-cdk , and submitted a documentation PR to update the URL: rustic-rs/docs#136

Thanks - I am happy to have a home under rustic-rs! Resolving this discussion.