https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
g
oh.. seems I’m cornered in pending delete stuff now..
Is it recommended to prevent such issues by using immutable stacks ?
l
No, that sort of thing shouldn't happen unless you interrupted a 
pulumi up
.
Normally it just won't happen. To fix it, you can try `pulumi refresh`: that will work in the future, I can't remember if they've implemented that yet.
Else you'll have to export the stack, delete the pending delete action, and import the stack.
g
Looks like it’s happening a lot to me; basically, Pulumi need to recreate a Target group but it is still in use by a listener si AWS emits an error; then Pulumi loops forever.. Maybe I’m missing a pattern here in order to automatically unregister the listener or update the targetGroup in place (and not trying to delete it first)
the targetGroup deletion - which can’t be done - is then becoming a pending delete on the very next run..
l
Are you creating the listener manually or something? If Pulumi is managing all the resources, this shouldn't happen.
Or are you somehow adding the listener to the target group in a way that circumvents Pulumi's resource dependency model? Maybe you're turning the target group ID into a string and using that to create the listener?
So long as Pulumi knows about all the dependencies, this simply shouldn't happen. I do it all the time, it never happens for me.
g
Let me check that
the Target group is created inline like so
Copy code
const service = new awsx.ecs.FargateService("my-service", {
  cluster: cluster,
  desiredCount: 1,
  waitForSteadyState: false,
  taskDefinitionArgs: {
    executionRole: containerRole,
    // taskRole: ?,
    container: {
      image: `${ECR_REPO_URI}/${backend.imageName}`,
      cpu: 512,
      memory: 1024,
      essential: true,
      environment: backend.environmentVariables,
      portMappings: [
        lb.createListener(`pv-listener`, {
          protocol: "HTTP",
          port: backend.loadbalancerPort,
          targetGroup: lb.createTargetGroup(`pv-tg`, {
            port: backend.containerPort,
            protocol: "HTTP"
          }),
        }),
      ],
    },
  },
});
and the lb like this
Copy code
const lb = new awsx.lb.ApplicationLoadBalancer("nginx-lb", {
  vpc,
  subnets: vpc.publicSubnetIds,
  securityGroups: [securityGroup.id],
});
from your answer it looks like I’m not using the right pattern indeed - I’ll look into other pulumi examples
@cuddly-alligator-37434 ^^
@little-cartoon-10569 would really appreciate knowing what part is wrong with it
l
I've never used awsx.lb, but that looks right. Stumped.
👀 1
g
oh.. 😞
maybe awsx is too magical and I should stick to aws
As we’re discussing how becoming productive and it appears you are on your side; do you only use aws and not awsx?
l
For load balancer, yes, aws. I had used awsx for Vpc, and found the use of method calls very different from all the rest of my code, fully driven by constructors and args. It seems I don't like mixing paradigms like that. By the time I was adding load balancers, I had decided to stick with the AWS classic module.
g
Maybe that’s the reason we don’t have the same experience; that’s very confusing to me as I though awsx was the future
Now I’m stumped like you 🙂
However my current thinking is now: Just separate the different Layers: Networking / Application in different Stacks; it may be easier to manage and prevent dependencies issues like that (not this one but some other we had with NatGateway in a VPC not ready for a ECSService to access the internet to get some packages...) (Stack being applied at different times)
Thank you for all your advices! I really appreciate
👍 1
3 Views
Open in Slack
PreviousNext
Powered by