General understanding on `pulumi preview` (delete-...
# general
r
General understanding on
pulumi preview
(delete-replace vs. in-place-update)
I’m just playing around with the azure provider, doing the quickstart tutorial for azure. I’m at this step: https://www.pulumi.com/docs/quickstart/azure/review-project/ and extended the resource group to have some tags.
The preview now says that the storage bucket will be replaced
Copy code
Type                         Name                  Plan        Info
     pulumi:pulumi:Stack          azure-infra-eval-dev
 ~   ├─ azure:core:ResourceGroup  pulumi-azure-eval     update      [diff: ~tags]
 +-  └─ azure:storage:Account     teststorage           replace     [diff: ~resourceGroupName]
b
--diff
arg is helpful to see exact changes
👍 1
r
which is probably caused by the inability to have the real output available (the name of the resource group that was changed by adding one tag):
~ resourceGroupName: "pulumi-azure-evalf9c2b004" => output<string>
I’m already watching the full diff which says the resource group is updated and the account is create-replacement as the
resourceGroupName
changed (which won’t change just because of the additional tags)
I now manually added one blob to the container to see if it will be lost and when I performed the upgrade in the end it was just an update and no create-replacement. Is this the usual behavior as the preview cannot definitely know if it can be done using a plain update?
Copy code
Do you want to perform this update? yes
Updating (dev):

     Type                         Name                  Status      Info
     pulumi:pulumi:Stack          azure-infra-eval-dev
 ~   └─ azure:core:ResourceGroup  pulumi-azure-eval     updated     [diff: ~tags]
pulumi preview --diff
also lists it as a replacement due to the “new”
resourceGroupName
.
~ resourceGroupName: "pulumi-azure-evalf9c2b004" => output<string>
b
Maybe there is no link between input args and output, any relation is per resource. if that is right, then yes it can't know whether value is going to change
On the other hand they claim that they can track this relation for data marked as secret, so maybe it is not the full picture
r
I’m using the sample of the azure tutorial. Just a resource group and a storage bucket that has this resource group name as an input (see first link)
The
storageAccount
does not live under the resource group itself but on the same level. If I’m right, indentation hierarchy only applies if things are a sub-resource from a component-kind-of-view, right?
b
yeah, both your resources are on the same level (as it should be)
r
There is a dependency from the
storageAccount
to the
resourceGroup
by referencing the `resourceGroup`’s name as property of the
storageAccount
like so:
resourceGroupName: resourceGroup.name,
So performing the update exactly does what is expected. The
resourceGroup
is updated in place and the
storageAccount
doesn’t change at all as its
resourceGroup
reference is still the same as before.
Just wondering if there is a better way to evaluate the previews or if one just needs to know how things behave and that the given preview is just a pessimistic one…
b
yes, update is fine, problem is that preview is not accurate
for preview to be accurate Pulumi need to track args -> output dependency.
they say that they do it for secrets, so maybe this particular provider needs to implement that fine tracking?
r
Could you give me a hint on where I should find this? Is this on the parent side or on the referencing/depending side? Having a look at the
pulumi/pulumi-azure
repo shows that most of that is generated using the terraform bridge tool. 🤔
b
Sorry, I remembered it wrong, it is very coarse:
When constructing a resource that has one or more secret inputs for a property, the entire corresponding output property of the resource is marked as a secret as well.
(from https://www.pulumi.com/blog/managing-secrets-with-pulumi/) , so it matches the behavior you see, as in it don't know which outputs depends on which inputs
r
I don’t see how this relates to the problem I observe, why there should be some secret when I create the
resourceGroup
. There is no secret input to the resource and the name should also not be marked as a secret as it is the public given name of the resource.
b
it is related as it is another indication that it can't map changes in inputs to individual outputs, therefore it can't know during planning stage that resurceGroup.name wont change when it's tags change