https://pulumi.com
Join Slack
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

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by