https://pulumi.com logo
Join Slack
Powered by
Either Pulumi is confused or I am, but I dont thin...
# general
m
Either Pulumi is confused or I am, but I dont think it is me. In the code attached 
crmCNAME
and 
crmTXT
are not working anymore. I used this code to create the resources, then I removed the resource that caused these to be created and it removed them from Cloudflare. so everything so far was working as expected. Then when I added a new resource in its place these did not get recreated. I tried 
pulumi refresh
but it didn't change anything with these resources. I manually went into cloudflare and created them. now when I run pulumi up I get:
Copy code
Diagnostics:
  cloudflare:index:Record (crm):
    error:   sdk-v2/provider2.go:515: sdk.helper_schema: expected DNS record to not already be present but already exists: provider=cloudflare@5.49.0
    error: 1 error occurred:
        * expected DNS record to not already be present but already exists
Untitled.ts
I think the problem is coming from something else. I figured out that the issue was that pulumi's state expected the TXT record to be there and the CNAME to need to be created. it seems to have straightened itself out after deleting just the CNAME record in Cloudflare. Now my question is, shouldn't the pulumi refresh have recognized that one was there and one was not and corrected my state?
l
Refresh looks for things in the code that may have changed in the cloud. If something isn't in the code, it doesn't check for them being in the cloud. In this case, you removed something from the code and deployed, so the code and state were correct. Whatever the problem was was on the cloud side: a resource remained in the cloud after it Pulumi thought it was deleted. Nothing that Pulumi can do via a refresh can fix that.
In order for Pulumi to make the code and state look like the cloud in that case, it would have to write new code for you and make the state line up.
A more exaggerated example of this would be if you created an empty Pulumi project, set up your credentials to point at a real cloud account, and ran 
pulumi refresh
with the intention of having it write your Pulumi project for you. It'd be wonderful.. but it just doesn't work like that 😞
m
The code was there. but I think I understand how that applies to me. I commented code out. Ran Pulumi up. Both resources were removed from the cloud. I then uncommented them after changing some other code and ran pulumi up. I received errors from down stream code that should have been set to depend on these to be created but had not been set that way. I assumed this was fine because those don't change unless other upstream code changes. The problem is that when I removed the resource that removed these resources AND commented out the code. I broke the chain. because I also did not have the downstream dependencies explicitly set, I couldn't simply just uncomment the code. So I manually created the resources and tried the pulumi refresh. but because the state was unaware of my shenanigans it didn't recognize both of the changes, only the one that had the correct downstream dependency.
This is a new type of "dependency hell" for me haha.
l
Yep, manually interacting with managed resources (or with ought-to-be-managed resources) is tricky. It's almost always better to do all this via code. And sometimes it's complicated enough that "just doing it" isn't going to produce the easiest results; a bit of planning, deciding when to do 
pulumi up --target ...
or 
pulumi destroy --target ...
, and so on, pays off.
6 Views
Open in Slack
PreviousNext
Powered by