https://serverless-stack.com/ logo
Join Slack
Powered by
I need to revisit <this> issue. I’ve now refactore...
# help
r
I need to revisit this issue. I’ve now refactored a reasonably complex stack into 13 small stacks. Everything builds correctly but when I deploy I’m getting the same error as I started this thread with for every resource - “Resource of type ‘AWS:SQS:Queue’ with identifier ‘x-y-omw-pso-be-sst-planBroadcastEventDlq’ already exists.” This happens when not setting an 
id
on the stack and when setting a different ID on each stack I also tried setting the same ID on each stack which I figured would fail and it did. What’s the right way to do this?
r
Problem is that your CloudFormation stack has a new name I think, and it tries to create the same exact SQS as the other stack. Since your old CloudFormation stack is not in use anymore, but still there, you then have two stack that create the same Queue, with the same name. If you can, just delete the old CloudFormation stack, then deploy the new ones
r
I see, we’re going to need to upgrade production deployments so interested to know if there’s a less nuclear option 😄
r
😂
I'm pretty sure there's one, but I do not know it yet 😉
r
🤞🏻
o
yes, the same thing happened to me, you can try to force a stack id with the same case that was used by default in previous versions of sst: 
_app_.stack(Stack, { id: 'stack' });
r
For all stacks?
the same ID?
r
It won't be possible to use the same ID for all Stacks 😞
r
Hmm, so back to square 1 🤔
o
in my case I had only one stack, the id works as a suffix and is at the end of the autogenerated name (which is what generates the name discrepancy)
r
I see. The main reason for refactoring was to break our huge stack up into smaller, functionality-based, stacks. So we’ve gone from 1 to 13
o
for example: before SST v1 the name was as follows: 
dev-ambito-dolar-stack
, after 
dev-ambito-dolar-Stack
I don’t know the name of your stacks and what would be the behavior if you put all of them: 
{ id: 'stack' }
r
I get
Copy code
Error: There is already a Construct with name 'x-y-omw-pso-be-sst-stack' in App
o
Indeed, with multiple stacks the behavior is different 😪
maybe in that case you could use the 
stackName
(https://docs.serverless-stack.com/constructs/Stack#configuring-stack-name) to leave it the same way it was before, but anyway I think everything this ends up being a workaround
r
Unfortunately the same error as specifying the same Id for each stack
yep
o
using in that way ? the same error ?
r
Copy code
import { coreResourcesStack } from './core/coreResourcesStack';
import { anotherStack } from './core/anotherStack';

export default function main(app: <http://sst.App|sst.App>): void {
  const stackName = `${app.stage}-omw-pso-be-sst-stack`;

  app
    .stack(coreResourcesStack, { stackName });
    .stack(anotherStack, {stackName });
}
Copy code
INFO: Deploying 13 stacks...
10.73 s
❌ the-stage-omw-pso-be-sst-stack: Stack [the-stage-omw-pso-be-sst-stack] already exists
o
ahhh, of course, what I was saying is that you manually put a name to each resource, it is correct that it fails that way. Going clean, before you had a single stack and now you have moved to several stacks, I don’t think you have a way to preserve the productive deploy and update it with the new version
if your idea was to preserve the structure of the previous version, maybe it was not a good idea to have divided everything into small stacks 🤔
but it is simply my opinion, maybe someone more knowledgeable can advise you in a better way
r
Yeah, well that was the main point as it was running to 1500 lines and really hard to follow 🤣😭
@thdxr - sorry to pull you in, do you have any thoughts on how to do this? Or do I have a database migration/restore on my hands?
f
Hey @Ross Coundon I usually follow a couple of flows when moving resources across stacks, which involves recreating: • Topics: create the new topic (ie. NewTopic) in the new stack -> update the application logic to publish both NewTopic and OldTopic -> deploy -> update the application logic to publish only to the NewTopic -> deploy -> remove OldTopic -> deploy • DB: create the new Table (ie. NewTopic) in the new stack -> update the application logic to write data to both NewTable and OldTable (only read from OldTable) -> deploy -> run script to have NewTable catch up to OldTable -> update application logic to read from NewTable -> deploy -> stop writing to OldTable -> deploy -> remove OldTable -> deploy
• Queue: create the new Queue (ie. NewQueue) in the new stack -> update the application logic to write data to NewQueue instead of OldQueue -> deploy -> check OldQueue is empty -> remove OldQueue -> deploy
t
yeah moving stateful resources really sucks. CDK has a new import command we need to investigate to make this easier
f
yeah CFN import is also an option
Either way, the resources have to be recreated or moved over (imported) when moving between stacks.
r
I see 😞 I can’t quite see how that process would work in the context of Seed and SST? I’d started to think of a simpler approach which would avoid having to make updates to the application code but that requires some downtime that looks something like this: 1. Create new SST stage using legacy stage as a template (which would necessarily have a new name) and deploy new stacks with processing turned off 2. Turn off processing on old app so queues are emptied 3. Copy data from old DB tables to new 4. Repoint URLs in frontend for API Gateway to the new app in the config 5. Turn on processing on new app
3 Views
Open in Slack
PreviousNext
Powered by