[TSP Migration]--powerbidedicated #34282
Conversation
Next Steps to Merge✅ All automated merging requirements have been met! To get your PR merged, see aka.ms/azsdk/specreview/merge. |
|
PR validation pipeline restarted successfully. If there is ApiView generated, it will be updated in this comment. |
API Change CheckAPIView identified API level changes in this PR and created the following API reviews
|
AzureRestAPISpecReview
added
ARMReview
NotReadyForARMReview
resource-manager
TypeSpec
…into TspMig-powerbidedicated
AzureRestAPISpecReview
removed
the
VersioningReviewRequired
| /** | ||
| * Represents the SKU name and Azure pricing tier for PowerBI Dedicated capacity resource. | ||
| */ | ||
| model CapacitySku { |
There was a problem hiding this comment.
I am asking because I am thinking the names 'CapacitySkuTier' and 'CapacitySku capacity' sound strangely redundant/confusing
There was a problem hiding this comment.
Also now I think about it... 'SKU of the capacity' and 'capacity of the SKU' are unexpectedly contradictory meanings of the word capacity aren't they?
Why talk about 'SKU of the capacity' at all though? Why not just say 'SKU of the reservation' or 'amount of SKU reserved'?
There was a problem hiding this comment.
I presume we can't fix this unless its SDK breaking, which is not ideal. #wontfix sound good?
| /** | ||
| * Represents an instance of an PowerBI Dedicated resource. | ||
| */ | ||
| model Resource { |
There was a problem hiding this comment.
Question I'd like to raise why aren't we autodetecting to reuse common types here, or at least having nice automatic comments that justify not doing it on the basis of a breaking change (and what change)
| /** | ||
| * Metadata pertaining to creation and last modification of the resource. | ||
| */ | ||
| model SystemData { |
There was a problem hiding this comment.
(I'm pretty sure there's no good reason for RPs to define SystemData themselves as opposed to referencing common types - only bad ones.)
| * The error object | ||
| */ | ||
| @error | ||
| model ErrorResponse { |
| /** | ||
| * An object that represents enumerating SKUs for new resources | ||
| */ | ||
| model SkuEnumerationForNewResourceResult { |
TimLovellSmith
added
the
ARMChangesRequested
openapi-pipeline-app
bot
removed
the
WaitForARMFeedback
ArthurMa1978
added
ARMSignedOff
openapi-pipeline-app
bot
added
WaitForARMFeedback
ArthurMa1978
added
ARMChangesRequested
| */ | ||
| create is ArmResourceCreateOrReplaceAsync< | ||
| DedicatedCapacity, | ||
| LroHeaders = ArmLroLocationHeader & |
| update is ArmCustomPatchAsync< | ||
| DedicatedCapacity, | ||
| PatchModel = DedicatedCapacityUpdateParameters, | ||
| Response = ArmResponse<DedicatedCapacity> | (ArmAcceptedLroResponse & { |
This PR migrates your latest version (identified by the tag in your readme.md) of swagger to TypeSpec. We already tried our best to make sure the TypeSpec represents same as previous swagger. Since we lack the business knowledge, please validate this PR again to make sure it's functional equivalent as before. The local validation step is at Getting started | TypeSpec Azure
Besides, TypeSpec encourages to follow ARM guidelines. Therefore, some representations in your previous swagger will be fixed to follow these guidelines. When you see differences in your local validation, please keep this note in mind. Here is the list of your anti-pattern:
Please reach out to TypeSpec Discussions Channel if there is any help needed.