Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve documentation for azurerm_postgresql_server storage_mb #7475

Open
thomas-riccardi opened this issue Jun 24, 2020 · 4 comments
Open

Comments

@thomas-riccardi
Copy link

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

azurerm_postgresql_server storage_mb documentation says Max storage allowed for a server. , it does not say what happens with storage Autogrow enabled:

  1. is it the limit for the auto growth? i.e. Autogrow will stop at that value (like in GCP)
  2. or is it the requested current size, and the auto growth can grow up from there?

1. is what I understand from reading the documentation (and coming from GCP world)
2. is what I understand from the portal UI: we cannot move the cursor below the specified value in storage_mb.

New or Affected Resource(s)

  • azurerm_postgresql_server storage_mb

References

@wasfree
Copy link
Contributor

wasfree commented Jun 24, 2020

Hi @thomas-riccardi,

so what happens right now if you define storage_mb + autogrow_enabled and exceed limit defined in storage_mb is:

Error: updating PostgreSQL Server "example-pg" (Resource Group "some-example-rg"): postgresql.ServersClient#Update: Failure sending request: StatusCode=0 -- Original Error: autorest/azure: Service returned an error. Status=<nil> Code="UnsupportedUpdate" Message="Cannot update StorageMB Downscaling for server"

So from my opinion you should define either auto_grow_enabled or storage_mb but not both. If you feel there is a lack in documentation, contributions are always welcome 👍

@thomas-riccardi
Copy link
Author

Hi @NickMetz,

I'm not sure I understand your scenario:

  • did you try to set storage_mb to a lower value than the current disk size?
  • or did you set storage_mb and autogrow_enabled then waited for autogrow to actually increase disk size so it goes above storage_mb, then terraform apply again which would try to re-set disk size to storage_mb, getting an error because it's lower than current value? (but how could actual disk size be larger than maximum size?)
  • other?

It seem storage_mb is in fact not a maximum disk size from a vm perspective with disk autogrow, but maybe a maximum storage usage from a postgresql user perspective, without autogrow.
i.e. storage_mb would just be the asked (vm) disk size, and with autogrow it doesn't mean anything: maybe the initial size, but then we should not ask again to set the value if autogrow effectively worked, because we would get the UnsupportedUpdate you got (asking for a vm disk size downscale is not possible).

If my understanding is correct, then indeed we should not use autogrow and storage_mb at the same time, but AFAIK it's not documented anywhere. (And there is then no way to ask for an initial disk size: what is the initial disk size?)

@wasfree
Copy link
Contributor

wasfree commented Jun 25, 2020

This senario was described above:

* or did you set storage_mb and autogrow_enabled then waited for autogrow to actually increase disk size so it goes above storage_mb, then `terraform apply` again which would try to re-set disk size to storage_mb, getting an error because it's lower than current value? (but how could actual disk size be larger than maximum size?)

Yes, storage_mb is not a cap. It's the provisioned storage.

It seem storage_mb is in fact not a maximum disk size from a vm perspective with disk autogrow, but maybe a maximum storage usage from a postgresql user perspective, without autogrow.

[Workaround] If you want to provision a postgres database server with initial storage size it's possible to use ignore_changes

i.e. storage_mb would just be the asked (vm) disk size, and with autogrow it doesn't mean anything: maybe the initial size, but then we should not ask again to set the value if autogrow effectively worked, because we would get the UnsupportedUpdate you got (asking for a vm disk size downscale is not possible).

Inital azure postgres server has 5 GB disk storage

If my understanding is correct, then indeed we should not use autogrow and storage_mb at the same time, but AFAIK it's not documented anywhere. (And there is then no way to ask for an initial disk size: what is the initial disk size?)

@thomas-riccardi
Copy link
Author

Thank you @NickMetz, it's all clear now! And thanks for the workaround with ignore_changes.

(In fact the Azure service documentation could be improved too).

Hopefully this ticket will help people before the documentation includes all that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants