[investigate] How many ARM brownfield service converted to TypeSpec need re-structure the operation groups

[weidongxu-microsoft]

We had a release request for VMWare (about a year ago), as brownfield service that migrated to TypeSpec.

During the release, we found that we need to write a large client.tsp to re-arrange the operation groups in TypeSpec, to make it backward compatible to that from Swagger.
Azure/azure-rest-api-specs#29308

A prior discussion https://gist.github.com/weidongxu-microsoft/fa420c35cf0611a62a8d155771dd3425
(the preference then, was to use client.tsp, as we only get one service -- however it still blocked by another issue in typespec-azure-resource-manager)

Our current situation likely be same, on either

• let them break
• write @client and @operationGroup and teach service to maintain it (this approach depends on a fix to typespec-azure-resource-manager lib) -- the maintenance of such client.tsp likely going to take efforts
• TCGC decorator or emitter option to re-group

There is no new release request for brownfield service that migrated to TypeSpec, since then (I've seen new TypeSpec migration for brownfield, just no release request).

Therefore, we had to preemptively do the investigation now, to see how many such cases exists. If there is large proportion of such cases, we'd like to have a solution that can avoid write and maintain a large client.tsp

[weidongxu-microsoft]

We now have more release requests from brownfield (that migrated to TypeSpec).

Summary:

• IotFirmwareDefense, no diff on operation groups
• Chaos, there is a small diff on operation groups, TypeSpec Experiments and ExperimentExecutions Interfaces maps to Swagger Experiments operation group.
• Avs/Vmware, there is large diff on operation groups, more than 5 TypeSpec Interfaces maps to WorkloadNetworks operation group.

A few seen (not yet have request)

• LoadTesting, no diff (the current client.tsp is wrong)

[weidongxu-microsoft]

We see a lot @operationId in TypeSpec from migration PR Azure/azure-rest-api-specs#34150 (comment)

From Pan, almost all such migration has some @operationId, which means the operation group of Swagger be different from that of TypeSpec.

[tadelesh]

1. since i have a fix for singleton resource, client.tsp could be a practical solution.
2. i suggest to add a legacy operation id decorator in arm lib and tcgc and autorest emitter add compatible logic for this legacy decorator.