Refactor TypeSpec with separate update models - #6462
Refactor TypeSpec with separate update models#6462Matthew Barnes (mbarnes) wants to merge 5 commits into
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mbarnes The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
caff07b to
c156e30
Compare
| * Budgets that have not been successfully drained from a node will be forcibly evicted. This is | ||
| * especially relevant to cluster upgrades. | ||
| * | ||
| * Valid values are in minutes and from 0 to 10080 minutes (1 week). |
There was a problem hiding this comment.
nit:
Don't need "Valid values are in minutes and from 0 to 10080 minutes (1 week)." if we have a @max and @min decorator since they're rendered into the description i believe. Just call out the units.
| * of a TypeSpec bug with updatable fields. The default value will be | ||
| * declared in a future API version once the TypeSpec bug is fixed. | ||
| * https://github.com/Azure/typespec-azure/issues/1586 | ||
| * If not specified, the default value is 'stable'. |
There was a problem hiding this comment.
remove what the default is here. Also an update we don't take a default, so remove this text entirely.
Explicitly specify the version so local copies stay synchronized with what the CI check uses.
…tions Use // comment style in the TypeSpec files for annotations that we don't want published in customer-facing documentation. Things like workarounds for upstream TypeSpec bugs, etc.
Based on a buried blurb in a TypeSpec How-To [1]: Note: The ArmResourcePatch* templates are not recommended. They rely on Lifecycle.Update visibility analysis to automatically determine which properties are included in the PATCH schema, but this analysis is only performed by the typespec-autorest emitter and will not be replicated in SDKs generated for the PATCH operation. Instead, spec authors should define a specific PATCH model and use the ArmCustomPatch* templates. This means we have to revert back to maintaining separate update models for our resource types. :( [1] https://azure.github.io/typespec-azure/docs/howtos/arm/resource-operations/#resource-update-operations-patch
Regenerating SDKs for all API versions to verify no E2E breakage.
| @@ -394,37 +508,22 @@ model ClusterAutoscalingProfile { | |||
|
|
|||
| /** maxPodGracePeriod is the maximum seconds to wait for graceful pod termination before scaling down a NodePool. | |||
| * The default is 600 seconds. | |||
There was a problem hiding this comment.
nit: remove "The default is 600 seconds".
| maxPodGracePeriodSeconds?: int32 = 600; | ||
|
|
||
| /** maxNodeProvisionTimeSeconds is the maximum time to wait for node provisioning before considering the | ||
| * provisioning to be unsuccessful. The default is 900 seconds, or 15 minutes. |
There was a problem hiding this comment.
nit: remove "The default is 900 seconds, or 15 minutes."
| maxNodeProvisionTimeSeconds?: int32 = 900; | ||
|
|
||
| /** podPriorityThreshold enables users to schedule "best-effort" pods, which shouldn't trigger autoscaler actions, | ||
| * but only run when there are spare resources available. The default is -10. |
There was a problem hiding this comment.
nit, remove "default" text.
| /** | ||
| * The number of worker nodes, it cannot be used together with autoscaling. | ||
| * Validation: | ||
| * - Minimum: 0 |
There was a problem hiding this comment.
remove min value specified in validation, it's in the decorator. Keep the max.
| * If unset the cluster nodeDrainTimeoutMinutes value is used as a default. | ||
| */ | ||
| @visibility(Lifecycle.Read, Lifecycle.Create, Lifecycle.Update) | ||
| nodeDrainTimeoutMinutes?: int32; |
There was a problem hiding this comment.
nit: add a Min Kim (@min) Max Schoening (@max) decorator, and remove valid values.
| * If not specified, the default value is 'stable'. | ||
| */ | ||
| @visibility(Lifecycle.Read, Lifecycle.Create, Lifecycle.Update) | ||
| channelGroup?: string; |
There was a problem hiding this comment.
"the default value is 'stable'" -> actually configure a default and set it. Then remove the default value text.
| * provider, must be issued to. At least one of the entries must match the | ||
| * 'aud' claim in the JWT token. | ||
| * | ||
| * audiences must contain at least one entry and must not exceed ten entries. |
There was a problem hiding this comment.
not needed, it's part of min/max items.
| * - "username": the mapped value will be "https://myoidc.tld#userA" | ||
| * - "email": the mapped value will be "userA@myoidc.tld" | ||
| */ | ||
| prefixPolicy?: UsernameClaimPrefixPolicy; |
There was a problem hiding this comment.
remove default text in here. It should have the default defined in the typespec base one.
Ben Vesel (bennerv)
left a comment
There was a problem hiding this comment.
So it looks like the default doesn't get rendered into the descriptions on https://learn.microsoft.com/en-us/rest/api. But the min/max values do. So keep the default text on creates, but min/max values are rendered so we can omit them from descriptions afaict.
Worst case we add them back in.
Since we're not using the ArmResourcePatchAsync template anymore, Azure/typespec-azure#1586 is no longer relevant for us. We can drop the workarounds.
3b68f27 to
b7aabbb
Compare
|
PR needs rebase. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
What
Refactors the TypeSpec API definition files for public preview compliance.
Primarily, we've been instructed to discontinue use of the
ArmResourcePatchAsynctemplate in favor ofArmCustomPatchAsync.This sucks.
ArmResourcePatchAsyncis nice because it auto-generates update model definitions in the JSON Swagger files. But it doesn't provide that benefit for generated SDKs and we've been largely disregarding SDK generation until now.ArmCustomPatchAsyncrequires a separate set of models for patch operations. These "update" models only include properties withLifecycle.Updatevisibility. This means we now have to maintain two copies of most of our TypeSpec models: one for PUT, another for PATCH.Testing
No new tests necessary. If I did this right then current tests should all pass.
Special notes for your reviewer
I tried my best to avoid churn in the JSON Swagger files, but the
Azure.ResourceManager.CommonTypespackage does not provide "update" models. So there is some unfortunate churn around the definitions for patching MSI and tags fields for tracked resource types.PR Checklist
If E2E tests are included:
demonstrate that the test is able to detect a defect/error and fail with
proper error message and logs which communicates nature of the problem.