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

cloudfoundry_app disk quota behaviour changed since v0.50.0 #427

Open
psycofdj opened this issue Nov 22, 2022 · 4 comments
Open

cloudfoundry_app disk quota behaviour changed since v0.50.0 #427

psycofdj opened this issue Nov 22, 2022 · 4 comments
Assignees
Labels

Comments

@psycofdj
Copy link
Member

psycofdj commented Nov 22, 2022

With the v0.50.0 release, we're experiencing an undocumented change on the behavior of the resource cloudfoundry_app.

  • the provider wants to scale the disk quota of the application from 256MB to 1024MB
  • the disk_quota attribute is not specified in our resource
  • the default disk_quota value in the bosh manifests of the targeted cloudfoundry is 256MB

My guess is that the previous version of the provider (v0.15.5) did not send this field to the CF API when the attribute was unspecified, which led to using the cloudfoundry default value. Now the provider specifies a default value of 1024 for this field, and use it for his call to CF API.

This is not a big deal from my point of view. We can easily specify the disk_quota for our applications in terraform. We were just surprised that the plan wanted some modifications. Perhaps we could just add this precision in the v0.50.0 changelog ?

@loafoe loafoe self-assigned this Nov 22, 2022
@loafoe loafoe added the bug label Nov 22, 2022
@loafoe
Copy link
Member

loafoe commented Nov 22, 2022

Hi @psycofdj yes this should be noted. I'll make the change shortly, thanks!

@loafoe
Copy link
Member

loafoe commented Nov 23, 2022

@psycofdj added a note to the release notes. We should keep this open to see if something can be done to solve this

@Thanhphan1147
Copy link
Contributor

@loafoe This behavior is also present for memory. What's your opinion on keeping such default values? should we revert to the previous behavior of v0.15.5?

@loafoe
Copy link
Member

loafoe commented Nov 30, 2022

@Thanhphan1147 if it is possible to detect the previous behaviour -- not sending default value if user did not declare any value -- that would be preferred yes. In that case the deployment default will be used, which is the expected behaviour.

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

No branches or pull requests

3 participants