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

Add note on app.ContainerApp API versions and KV secrets #3284

Merged
merged 2 commits into from
May 14, 2024

Conversation

thomas11
Copy link
Contributor

@thomas11 thomas11 commented May 14, 2024

Prompted by #3243. When creating a ContainerApp referencing a Key Vault secret via URL, Azure can at least sometimes respond with "invalid: value or keyVaultUrl and identity should be provided". This is a bug in the particular API version we use as default.

This PR adds a warning and a pointer later API versions to the registry docs.

Copy link

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.

Copy link
Member

@danielrbradley danielrbradley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks helpful.

Out of interest, have we tried bumping the default version just to see if it's compatible?

@thomas11
Copy link
Contributor Author

Out of interest, have we tried bumping the default version just to see if it's compatible?

I ran this, indicating that it's not.

❯ schema-tools squeeze -s bin/schema-full.json --old azure-native:app:ContainerApp --new azure-native:app/v20230501:ContainerApp
Found 2 breaking changes:
Resource "azure-native:app/v20230501:ContainerApp" missing input "workloadProfileType"
Resource "azure-native:app/v20230501:ContainerApp" missing output "workloadProfileType"

@danielrbradley
Copy link
Member

Out of interest, have we tried bumping the default version just to see if it's compatible?

I ran this, indicating that it's not.

❯ schema-tools squeeze -s bin/schema-full.json --old azure-native:app:ContainerApp --new azure-native:app/v20230501:ContainerApp
Found 2 breaking changes:
Resource "azure-native:app/v20230501:ContainerApp" missing input "workloadProfileType"
Resource "azure-native:app/v20230501:ContainerApp" missing output "workloadProfileType"

Great, thanks for confirming!

@thomas11 thomas11 enabled auto-merge (squash) May 14, 2024 07:59
Copy link

codecov bot commented May 14, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 55.33%. Comparing base (a1d5194) to head (af586ec).

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #3284   +/-   ##
=======================================
  Coverage   55.33%   55.33%           
=======================================
  Files          66       66           
  Lines        9930     9930           
=======================================
  Hits         5495     5495           
  Misses       4001     4001           
  Partials      434      434           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@mikhailshilkov
Copy link
Member

mikhailshilkov commented May 14, 2024

If we find that the default version is broken in some meaningful way, I would support us bumping it up to a better version even with minor breaking changes. It's a trade-off, but if we can take a closer look at what happened with workloadProfileType and confirm it's not reducing the functionality, I think a minor break is worth to fix the defaults.

Side note: please add some description to the PR. I know it feels like busywork, but I'd really want to encourage us to keep a high bar on PR text quality.

@thomas11 thomas11 merged commit 9ee2174 into master May 14, 2024
23 checks passed
@thomas11 thomas11 deleted the tkappler/apps-kv-3243 branch May 14, 2024 08:34
@thomas11
Copy link
Contributor Author

thomas11 commented May 15, 2024

If we find that the default version is broken in some meaningful way, I would support us bumping it up to a better version even with minor breaking changes. It's a trade-off, but if we can take a closer look at what happened with workloadProfileType and confirm it's not reducing the functionality, I think a minor break is worth to fix the defaults.

The difference in the spec is that workloadProfileType was replaced by workloadProfileName. Both are simple strings, but their sets of allowed values seem to be different based on the examples: "workloadProfileType": "GeneralPurpose" vs "workloadProfileName": "My-GP-01". Here are the valid names per current docs.

So, seems like changing the API version would require everyone to update their code, not only changing the property name but also looking up the correct value. On the positive side, it's limited to that one property.

@thomas11
Copy link
Contributor Author

Addendum: v3 of the provider is also not too far away. Overall, we've decided to leave the API version as-is.

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

Successfully merging this pull request may close these issues.

None yet

3 participants