s

    strong-helmet-83704

    1 month ago
    I’ve noticed that sometimes Pulumi will take multiple runs to complete all of its tasks… Is this normal or expected in some situations?
    s

    steep-toddler-94095

    1 month ago
    It shouldn't normally take more than a single run to complete everything. It's likely it's not able to draw the dependency tree correctly. Sometimes it's due to an obvious oversight in the user's code, and other times it could be due to something trickier, for example: a Docker image's baseImageName is known before creating the image, so Pulumi will attempt to update a Deployment before building the image. If you have trouble figuring out what's going on, if you give more specifics on the tasks that don't run the first time maybe we can help
    s

    strong-helmet-83704

    1 month ago
    Admittedly this only seems to happen with larger / more complex dependency structures. Is there some way we can explicitly signal to Pulumi resources that it should depend on something else?
    s

    steep-toddler-94095

    1 month ago
    s

    strong-helmet-83704

    1 month ago
    (e.g, we have a resource which requires an eip, we perform a change which tries to create a new natgw which tries to associate the eip… but the eip is still associated until the natgw releases it…) If we could instruct Pulumi to delete the natgw before it creates a new one, that would probably fix this
    I think technically in this case i need to specify
    delete_before_replace=True
    Why is it that when a resource is renamed, Pulumi wants to re-create the resource?
    s

    steep-toddler-94095

    1 month ago
    Pulumi needs to keep track of the mapping between its representation in Pulumi statefile with the resource's UID in the cloud, and the resources name is part of the identifier. If you change the identifier, it counts as a removal of the resource associated with the old identifier and the addition of a resource with the new identifier. If you try to think about how one might implement it so that it doesn't delete the old resources and simply adopts the old resources state into the new ones, you'll find that it's impossible to guarantee the desired result 100% of the time without additional information on how exactly to do this remapping. Luckily Pulumi allows you to do this through aliases!
    s

    strong-helmet-83704

    1 month ago
    Great point on the implementation. I will check out aliases
    I’m setting
    opts=pulumi.ResourceOptions(delete_before_replace=True, provider=provider_options)
    on the natgw (which binds to an eip) but a rename operation still fails. It still tries to create the natgw before deleting the old one. (all creates are listed before the deletes)
    s

    steep-toddler-94095

    1 month ago
    by "rename" do you mean renaming the Pulumi resource? not the AWS resource? just making sure i understand. if you do mean renaming the Pulumi resource (basically the first parameter in the class instantiation) then I dont think the
    delete_before_replace
    parameter handles that case. It's meant for cases where the Pulumi URN stays the same, but you are trying to change an immutable property of the resource, which the cloud provider requires that it be recreated. If you are trying to rename the Pulumi resource without changing the cloud resource, you should use the alias property for this.
    s

    strong-helmet-83704

    1 month ago
    Yes I mean renaming the pulumi resource. This is not a real requirement, but something i ran into. Perhaps
    retain_on_delete=True
    will maintain the natgw with the eip attached… ?
    curiously i notice
    “retainOnDelete”: true
    specified in the state, but delete_before_replace was not
    s

    steep-toddler-94095

    1 month ago
    Renaming it with alias wont even trigger a recreate so these properties dont even come into the picture