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 back resource hierarchy information when merging Compute specs #1906

Open
Tracked by #1850
pshao25 opened this issue Nov 25, 2024 · 0 comments
Open
Tracked by #1850

Add back resource hierarchy information when merging Compute specs #1906

pshao25 opened this issue Nov 25, 2024 · 0 comments
Assignees

Comments

@pshao25
Copy link
Member

pshao25 commented Nov 25, 2024

To migrate Compute swagger to TypeSpec, now we split it into several sub service like Compute, Gallery, Disk, Sku, etc. We translate these sub swagger into TypeSpec separately. We currently validate the TypeSpec by checking the SDK API. Later we will need to merge these several sub TypeSpec back into one TypeSpec.

The problem is when we do the splitting, some resource hierarchy information is lost. For example, when we do conversion for DiskRestorePoint in the sub service Disk, we will go through the whole swagger and find there is no parent for this resource. Therefore, DiskRestorePoint will become a resource without a parent in the Typespec. However, its parent and grandparent are actually in the "external" Compute sub service.

Therefore, if we are going to merge these sub services into one spec later, we cannot simply combine them together, we should add this resource relationship information back too!

Don't rely on SDK API comparison to uncover this issue! Since we now don't have getArmResources so we calculate resource information in the generator according to the input swagger. Therefore, using the generated swagger to generate SDK still have correct resource information.

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

No branches or pull requests

2 participants