Good morning. The question isn't Azure specific, b...
# azure
Good morning. The question isn't Azure specific, but since it is related to an Azure resource I will post it here. We create Postgres databases via the Pulumi Azure Native SKD. Recently we enabled autogrow for the storage, which worked nicely, but we encountered an issue where a database has grown more than what we provide in the StorageSizeGB field. Now pulumi tries to update the resource with a smaller size than the current, which isn't allowed by Azure. We tried ignoreChanges, but that doesn't ignore the field completely, it just uses whatever value we set initially. Is there a workaround for this? Ideally we would like to set StorageSizeGB only on create, and from then on let autogrow do the job. Can a user choose which fields to set on create vs update? Thanks beforehand. By the way, the code in has the exact same problem.
Hi Paul! Can you share your plan when you do a preview? pulumi preview --diff, and also the code that you use (including the code using the ignoreChanges parameter)
Hello Mats! I am a colleague of Paul, our configuration does not allow us to easily run pulumi preview unfortunately. Code snippet:
Copy code
import (
  dbforpostgresql "<|>"

server, err := dbforpostgresql.NewServer(ctx, "server", &dbforpostgresql.ServerArgs{
  ServerName:                 pulumi.String("name"),
  CreateMode:                 pulumi.String("Create"),
  Storage: dbforpostgresql.StorageArgs{
    AutoGrow:      pulumi.String("Enabled"),
    StorageSizeGB: <http://pulumi.Int|pulumi.Int>(storageGB),
Copy code
Requested data Disk size '131072' cannot be less than current size '262144'. Please make sure to request correct disk size.
The snippet code works on creation and as long as autogrow did not come into effect. IgnoreChanges seemingly still sends the value that succeeded last time, being unaware of azure having scaled up the instance. The "storageGB" variable we set would ideally only be used on creation.
Are you certain that the string literal value you've given in
is correct? Because
does exactly what you are looking for and I doubt that the value you've given it is targeting the property in question.
For example, should it be
? Note the camelCase
instead of
From Pulumi Docs:
The property names passed to
should always be the “camelCase” version of the property name, as used in the core Pulumi resource model. For example, a property named
would turn into
is also a parameter, which is nested under
so I think @clever-sunset-76585 is correct that it would be
but you should see that if you run
pulumi pre --diff --refresh