https://pulumi.com logo
Join Slack
Powered by
I have question related to the migration of `@pulu...
# azure
p
I have question related to the migration of 
@pulumi/azure-nextgen
to 
@pulumi/azure-native
… If I have an import like 
import * as operationalinsights from "@pulumi/azure-nextgen/operationalinsights/v20200801";
is it save to change it to the new version-less import: 
import * as operationalinsights from "@pulumi/azure-native/operationalinsights";
or should I keep the version in the import?
t
What do you mean by “safe”?
p
will it change my existing resources? or is it better to keep the versions? whats the recomendation?
t
You didn’t mention which resources you use. The versions are aliased, so it won’t need to re-create them from scratch. But if api versions don’t match, there may be differences in inputs/outputs.
You can first move to 
native
without changing the version and then decide separately.
p
well, there are many different resources… so If I understand you correctly: if it compiles then it should also not change the existing resources (e.g. WebApp, AppServicePlan, DiagnosticSetting, insights.Component, …).
so basically I’m a bit unsure whether I should stick with the versioned imports I have or if I should switch to version-less. Currently it looks like two Typsescript-API are fine/compatible (in my case at least)
t
Unless your named versions are somehow old (very different from the version-less), you should be fine switching over.
Even if it compiles, you may see a diff when you run 
pulumi up
(e.g. you updated to a version which has different defaults).
It’s hard to make blank statements that would be universal here
Another tradeoff: versionless resources may get breaking changes between 0.x and 0.(x+1) of the provider and 1.x and 2.x, for example.
p
👍 thanks, that helps
Sorry to bother you again… reading about the migration, https://www.pulumi.com/blog/full-coverage-of-azure-resources-with-azure-native/#migrate-from-azure-nextgen-to-azure-native it says: 
Run pulumi up and make sure the program ran successfully. The preview should show no changes.
In my case this is not the case, it seems to dismiss all exsiting resources and wants to recreate every single one 😞
t
That doesn’t sound good. Do you use custom providers (passed through resource options)?
p
I do something like a provisioner (based on https://github.com/pulumi/examples/blob/master/aws-ts-ec2-provisioners/provisioners/provisioner.ts) to execute some shell commands. But these are at the very end of the dependency graph. (e.g. once the WebApp is created, it will run a command to configure a CustomDomain (required because of circular dependencies in the azure API)
other then that I have many custom resources (e.g. 
extends pulumi.ComponentResource
)
t
If looks like resource hierachy changed? What should be the parent of the 
CustomCloudflareDomain
resource?
I mean, it’s trying to delete 
cloudflare:index:Record
which can’t be related to the migration nextgen->native
p
hmm, here is the output of 
pulumi stack
https://gist.github.com/imod/10daa9970217ea97b93382289592dca1#file-output-of-current-pulumi-stack - I need to dig into this more deeply I guess
I did also do an update of the cloudflare dependency - I’' revert that
t
Ok, so you parented component resources to custom resources and now you update those custom resources to the new library and that doesn’t quite work. That’s an interesting scenario.
p
is that something strange? I thought that would always be the case when using custom resources. would you not set the parent of the “real-resource” to the custom resource?
would you have expected that to work or am I doing something to exotic here?
t
Side note: In our terms - “custom” = real, e.g. azure-native, and “component” is what you defined.
p
ah ok, sorry - I’ll try to use the correct terms next time 🙂
I think all I’m doing with the whole parenting thing is what is described here: https://www.pulumi.com/docs/intro/concepts/resources/#creating-child-resources - I create custom resources inside the constructor of my component and set the component as the parent of the resource 
{ parent: this }
t
Yes, I’m not saying you are doing something illegal. Probably, worth filing an issue with a repro. The only workaround I can think of so far is start aliasing all resources manually to make sure the hierarchy holds.
p
@tall-librarian-49374 I created an issue with a small example project: https://github.com/pulumi/pulumi-azure-native/issues/674
t
Thank you. I think that, short-term, you should probably edit your state manually. Export it with 
pulumi stack export
, back it up, then replace 
azure-nextgen
with 
azure-native
and import again. Crude but should work.
p
thanks @tall-librarian-49374 I’ll try that!
5 Views
Open in Slack
PreviousNext
Powered by