https://pulumi.com
Join Slack
is it expected that when you upgrade a provider through a major version, it will no longer work with...
# general
i
is it expected that when you upgrade a provider through a major version, it will no longer work with older resources? I upgraded to 
@pulumi/cloudflare
v6 and now getting these errors on preview:
Copy code
cloudflare:index:ZeroTrustAccessPolicy (c1-policy):
    error: objectEncoder failed on property "include": encList failed while encoding element 0...
l
Not expected, but definitely possible. Newer versions of providers may stop supporting deprecated API request parameters that older versions still support. Sometimes this requires a corresponding code change, to use whatever the newer version of the API requires.
In my experience, the provider SDK docs provide enough info to resolve the issues.
Just checking the TF provider change logs, and it looks like the zero trust stuff changed a lot between 4.x and 5.x. Probably an expected break.
i
ah okay, in this case is it easier just to • downgrade provider • re-run 
up
with problematic resources removed • upgrade provider • bring program in line with latest API • re-run 
up
l
I don't know if there's a one-size-fits-all answer. That would work, but there might be easier options. Have you tried a refresh? That might get things back in line with minimal fuss.
Well, not fully in line. You might get the correct values in state, then you'd have to figure out what the those values look like in code, and change the code to match the state.
I feel like this solution has worked for me in the past. But I've never had this particular provider upgrade.
i
I think to avoid the breaking changes a lot of things were duplicated eg. 
AccessPolicy
became 
ZeroTrustAccessPolicy
with the idea being the former would provide backwards-compatibility but it looks like it wasn't done correctly, only the top-level resources were kept backwards compatible, nested props like 
AccessPolicyInclude
broke
l
Ouch
i
it looks like 
ZeroTrustAccessPolicyInclude
was meant to carry the breaking change, but it's been accidentally applied to the backwards-compat resources too :(
l
So you can resolve it by updating the code to match the new expected syntax?
I feel like a refresh might be required (before or after the code change) else you'll end up with code and cloud matching, but state lagging behind. Which will result in Pulumi thinking it has to push changes out, even though it'll just be setting x = x, in essence.
i
im not sure whats happening. i used 
pulumi stack export > state.json
and done some editing then imported the updated state but its still throwing an error on preview with 
objectEncoder failed on property "certificate": Expected an Object PropertyValue, found bool ("{false}")
even though that property "certificate" is no longer in my state, and is also not being returned by the cloudflare API. i'm not sure where i'ts coming from
ok managed to get it working, that was really not fun. created a new stack using the ZeroTrustX resources, exported its state spliced the desired state into the old stack, replacing unique values, and re-running 
up
without 
--refresh
now i just need to do that 2 more times 🤣
oh yowsers.. looking through the list of issues on the TF provider and they really borked the zero trust resources through this migration
5 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