Migrate swagger to TypeSpec for brownfield service

[pshao25]

Exit Criterion

Long term

1. Functional equivalent TypeSpec
2. Functional equivalent SDK from TypeSpec without breaking change

Short term

1. Functional equivalent TypeSpec
2. Functional equivalent SDK from swagger generated from TypeSpec without breaking change

TypeSpec feature gap for Compute

Compute is where our current effort is, which has high priority.

Tasks

Beta Give feedback

1. Common type replacement for Compute #1849
   needs-area needs-info +2
   
2. [ARM]: Support resource with multiple paths #234
   design:needed external:mgmt external:swagger-converter lib:azure-resource-manager +4
3. Override description from operation template #1844
   needs-area +1
   
4. Linter rule @azure-tools/typespec-azure-core/casing-style is not accurate #1845
   feature lib:azure-core +2
5. Provide an API for non resource operations #1846
   needs-area +1
   
6. Can x-ms-azure-resource be safely removed #1474
   design:accepted lib:azure-resource-manager +2
   
7. Should not expect armResourceOperations on ArmProviderActionAsync #1848
   needs-area +1
8. [TCGC] Add @alternateType to change the type of a property (with scope) #1757
   lib:tcgc +1
   
9. Support "x-ms-format": "duration-constant" #1901
   needs-area +1
   
10. Add back resource hierarchy information when merging Compute specs #1906
    needs-area +1
    
11. List resources with two different resources but same resource type #1911
    design:needed lib:azure-resource-manager +2

SDK diff

Tasks

Beta Give feedback

1. Compare Java SDK for compute TypeSpec migration azure-sdk-for-java#43116
   Client Compute Mgmt - Track 2 needs-team-attention +4
   
2. Compare python SDK for compute TypeSpec migration azure-sdk-for-python#38620
   Compute Mgmt needs-team-attention +3
   
3. Compare JS SDK for compute TypeSpec migration azure-sdk-for-js#32007
   Compute Mgmt needs-team-attention +3
   

Diff tool gap

Though they are all tool issues, it is important to fix with high priority. Because without these, it is difficult for us to tell whether the conversion is correct.

Tasks

Beta Give feedback

1. Improve sortOpenAPIDocument: order the operation parameters in group #1855
   needs-area +1
   
2. Improve sortOpenAPIDocument: order model peoperties and operations #1856
   needs-area +1
   

TypeSpec feature gap for others

Tasks

Beta Give feedback

1. Partial resources in TypeSpec #1428
   design:needed lib:azure-resource-manager +2
2. Expanded resource (resource type is not constant) in TypeSpec #1261
   design:needed lib:azure-resource-manager triaged:core +3
3. Prepare detailed document for brownfield service onboard #1784
   docs lib:azure-core lib:azure-resource-manager +3
4. Two resources with one properties flattens while the other not #1931
   lib:tcgc +1

SDK feature gap

.net

Tasks

Beta Give feedback

1. How to handle configurations in autorest.md after migrating to TypeSpec autorest.csharp#5164
   0 of 2
   +0
2. Known issues for migrating Compute to TypeSpec autorest.csharp#5168
   0 of 1
   +0

Tool gap

For compute, we are now converting manually. But all these efforts should be integrated into converter so that following services could do automatically. What's more, the tsp-client sort-swagger and tsp-client compare should be improved as well.

Tasks

Beta Give feedback

1. Implement multi-path design to converter autorest#5037
   openapi-to-tsp +1
2. Honor original response in swagger autorest#5038
   openapi-to-tsp +1
3. Customize resource action path autorest#5039
   openapi-to-tsp +1
4. Use original body for resource operation autorest#5040
   openapi-to-tsp +1
5. Generate examples with its original path autorest#5041
   openapi-to-tsp +1