Creating 2nd CloudFormation stack, errors creating already-existing resources

[aidanhmiles]

Hi there,

TLDR: I'm trying to clone an existing deployment into a new subdomain so I can have a dev/prod split. Cloudformation is failing on resources already existing. Is there an expected method for adjusting the Hubs CloudFormation template to handle already-existing resources?

Here's what fails:

During my first from-scratch deployment, I had to do a little bit of pruning because my primary domain, plus SES configuration, already existed. Am I just stuck trial-and-erroring my way through the resource creation stanzas in CF for these other errors?

Really, I'd like to clarify a couple things:

1. Is there a already-known (or intended) way to get around these errors? I believe what I did for the original issues with SES and the Route53 domain were just to remove the items from the CF template outright, while crossing my fingers that I didn't break the template.

2. Should I be able to use my same apex domain and same link/internal domains with a new Hub subdomain?

The docs page for Backup and Restore says I should be able to restore from a backup into the same region as a previous deployment. It also says

it is suggested you first create a new, separate stack on a different domain from the backup before deleting the old stack, to confirm the backup contains the data you expect it to.

Does the above specifically mean "a new apex domain", and not a new subdomain? I.e. I already have hub.a.com, can I choose hub-dev.a.com or must I choose hub.b.com? Also, must I choose new internal or link domains? I assume not but want to clarify.

Thanks again for all your help and for a great project.

[robinkwilson]

Using the same internal + link domains, I have not seen anyone successfully deploy a second deployment.

Using a different subdomain for the main domain, I have not heard anyone successfully deploying a second deployment. -- you'd be trailblazing if you did!

I'd recommend deploying a second stack with completely different domains.
The backend would stay in sync because of our HC auto-update system.
You'd iterate with the custom client by using npm run login and npm run logout to login to each stack, then deploy the same custom client to each.

[robinkwilson]

The parameters and the scenes would need to be updated in each. You bring up a great point this would be a good feature to have. Please make an issue in https://github.com/mozilla/hubs-cloud to track this.

[aidanhmiles]

Ok, thank you for clarifying! Saved me a lot of time on what would have been dead-ends.

The issue you'd like to see is specifically related to migrating params and scenes/assets to a new domain?

[aidanhmiles]

For anyone else's information who may be interested in this idea:
(granted, I'm brand new to CloudFormation, but...)

It appears that you should be able to reconfigure the launch template to import certain resources rather than try to create them. However, it appears to be a doozy of a task and a lot of details to comb through. I had to do a small amount of this initially, and it should definitely be possible, but instead of that I'd recommend rewriting the CloudFormation tpl into something like Terraform or Pulumi that a) is just code, b) can have an interface for which resources to create and which to import, and c) doesn't have a web interface that makes Firefox complain :p

Thanks again for your help @robin-k-wilson