https://pulumi.com
Join Slack
Menu
Home
Archive
This message was deleted.
# python
s
This message was deleted.
e
dictionary order is not guaranteed to be consistent
but this is only a problem if your changing from dictionaries (unordered) to lists (ordered) in your program
c
Dictionary ordering in python is now guaranteed, though it's not a great idea to rely on the order of those keys (even though it's been a language feature since 3.7). I'd love to see what your program looks like to determine where this reordering is occurring.
s
This is something I didn’t noticed until i ran the stack on another system… venv and pycache were purged / rebuilt. Since then i’ve been able to reproduce it after purging these dirs… which makes me think the order is being maintained in the cache somehow… I’m building a dictionary in a loop with values which are Pulumi resources…
@calm-hairdresser-54232
c
Aha, that makes sense - I would not expect the resources themselves to come back in a deterministic order.
sad panda 1
s
What is the right way to do this?
c
I'd have to see an example of the code which is causing problems to know for sure, but I wouldn't depend on the order of asynchronous cloud operations when constructing objects / dictionaries.
👍 1
s
How would we build a dictionary with x resources assigned as values? And when re-running, get the same resources re-assigned to the same place in the dictionary?
basically i need to create x resources and store those objects someplace to operate on them later…
c
Are you operating on them within the same stack, or in a different one?
s
same stack
c
It depends on the operations and the resources, but could you not just operate on the resources themselves rather than storing them in a dictionary? Can you share a code snippet to demonstrate what you're trying to accomplish?
s
Copy code
for subnet in environment['subnets']:
        az = environment['subnets'][subnet]['az']
        if environment['subnets'][subnet]['type'] == "public":

            public_subnets[az] = myclass.Subnet(
                az_id=az,
                type="Public",
                vpc_id=vpc.id,
                cidr_block=subnet,
            )
then later on, i’ll use the public_subnets[“az-code”] to deploy other resources
c
and 
environment['subnets']
is created dynamically somewhere above in a loop?
s
Yes that is statically defined and is always the same
c
I'm curious what your 
pulumi preview
output looks like in this case - could you post that as well?
s
It’s different every time… but nothing happens while cache is maintained. Later in the program i’m creating resolver endpoints and something like this occurs
Copy code
~   └─ aws:route53:ResolverEndpoint  thing_ResolverEndpoint  update     [diff: ~ipAddresses]
c
Ah, and the order of the ipAddresses is triggering this diff?
s
yes… it changes sometimes because i’m selecting 2x keys in the dict for each ip
c
I think I would need to see the actual code to reproduce, then. It's hard to say with the information here so far.
s
I wish i could send you the entire codebase haha
But yeah this makes complete sense… I’m re-building the dictionary every time and the Pulumi resource is going to return a potentially different resource on each subsequent execution… (unless we keep that dict cached, which is not a reliable thing)
e
If your building lists based on iterating dicts I'd suggest you sort the lists after building them and before using them
s
something very weird is going on… and it’s gonna take me a while to get to the bottom of it… but i’ll check back here when i have more info. Thanks for your help!
But for now…I’m just terribly confused with update diff’s which are actually not different
Copy code
~ aws:route53/resolverEndpoint:ResolverEndpoint: (update)
        [id=rslvr-out-92d9]
        [urn=urn:pulumi:ResolverEndpoint]
        [provider=urn:pulumi:cfa6a9e0043f]
      ~ ipAddresses: [
          ~ [0]: {
                  ~ subnetId: "subnet-1725d" => "subnet-1725d"
                }
          ~ [1]: {
                  ~ subnetId: "subnet-98b2b" => "subnet-98b2b"
                }
        ]
I’m quite sure now that this is a pulumi_aws bug which was introduced sometime between
Copy code
pulumi==3.40.1
pulumi-aws==5.16.0
and now…
e
Copy code
~ ipAddresses: [
          ~ [0]: {
                  ~ subnetId: "subnet-1725d" => "subnet-1725d"
                }
          ~ [1]: {
                  ~ subnetId: "subnet-98b2b" => "subnet-98b2b"
                }
        ]
Probably worth raising this as an aws issue at https://github.com/pulumi/pulumi-aws. Spurious diffs like that that are generally the provider doing odd things.
👍 1
s
OK I’ll raise an issue and link it here
Looks like this has been known about for a while and still not fixed https://github.com/pulumi/pulumi-aws/issues/2294
Seems like another upstream terraform provider issue. pulumi-aws maintainers claim to have their hands tied. These seem to happen often. I guess this will drive us toward using pulumi native libraries (when they are mature enough)
e
aws-native and aws legacy should play nicely together, I've seen the providers team suggest a few times to switch over to aws-native for just one or two resources that users are having issues with in the terraform based provider
s
They do work together? I’d heard otherwise but i’ll give that a go.
aws-native does not support resolverEndpoints…
I will need to version lock to 
pulumi-aws==5.21.1
to workaround this until something changes
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