-
Notifications
You must be signed in to change notification settings - Fork 5.1k
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
[Hub Generated] Review request for Microsoft.KeyVault to add version stable/2021-10-01 and preview/2021-11-01-preview #16156
[Hub Generated] Review request for Microsoft.KeyVault to add version stable/2021-10-01 and preview/2021-11-01-preview #16156
Conversation
…6-01-preview to version 2021-10-01
Hi, @osmuller Thanks for your PR. I am workflow bot for review process. Here are some small tips. Any feedback about review process or workflow bot, pls contact swagger and tools team. vsswagger@microsoft.com |
[Call for Action] To better understand Azure service dev/test scenario, and support Azure service developer better on Swagger and REST API related tests in early phase, please help to fill in with this survey https://aka.ms/SurveyForEarlyPhase. It will take 5 to 10 minutes. If you already complete survey, please neglect this comment. Thanks. |
Swagger Generation Artifacts
|
Hi @osmuller, Your PR has some issues. Please fix the CI sequentially by following the order of
|
This comment has been minimized.
This comment has been minimized.
@
I removed the duplicate, but I left the others. Fixing those will require a thorough look at our swagger and we don't have cycles at this time. |
@ArcturusZhang could you help check go track2 failure? Can we ignore it for the PR merging due to the urgency of the PR merging? |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Were just new api-versions added, or were there other changes? I'm trying to use the diffing tool e.g., https://portal.azure-devex-tools.com/tools/diff/eyJzb3VyY2VVcmwiOiJodHRwczovL2dpdGh1Yi5jb20vQXp1cmUvYXp1cmUtcmVzdC1hcGktc3BlY3MvYmxvYi9tYWluL3NwZWNpZmljYXRpb24va2V5dmF1bHQvcmVzb3VyY2UtbWFuYWdlci9yZWFkbWUubWQiLCJ0YXJnZXRVcmwiOiJodHRwczovL2dpdGh1Yi5jb20vQXp1cmUvYXp1cmUtcmVzdC1hcGktc3BlY3MvYmxvYi81ZGQ3YzhmYzJjY2M4Zjk3OGU4ZDI5MmMzMmViZDZjOGZlOGM4YTk2L3NwZWNpZmljYXRpb24va2V5dmF1bHQvcmVzb3VyY2UtbWFuYWdlci9yZWFkbWUubWQiLCJzb3VyY2VUYWciOiJwYWNrYWdlLTIwMTktMDkiLCJ0YXJnZXRUYWciOiJwYWNrYWdlLTIwMjEtMTAifQ== but it's not rendering the diff, and manually reconciling changes outside of api-version changes with the latest swagger is incredibly time-consuming.
If other changes were made, is it possible to back those out of the PR and submit a PR just for adding new versions, then another PR for the changes atop those? In git, you could do so like so:
git branch additional-changes
git reset --hard <commit ID that OpenAPI hub created with just new api-versions>
git push --force # update the PR
# wait for that to be merged
git fetch upstream main
git rebase --onto upstream/main HEAD additional-changes
git checkout additional-changes # may not be necessary; IIRC, above command switches
It's mostly just the new api-versions, but the SDK teams did some changes on their backend that broke their tooling so I had to add those "fixes" |
@zhenglaizhang what is the status of this? can it be merged? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comments for one version would apply to the other one you're adding. I do recommend defining Attributes
in common.json and using an allOf
reference for both keys and secrets to make sure definitions are consistent. You can copy from data plane if you with.
"nbf": { | ||
"x-ms-client-name": "NotBefore", | ||
"type": "integer", | ||
"format": "int64", | ||
"description": "Not before date in seconds since 1970-01-01T00:00:00Z." | ||
}, | ||
"exp": { | ||
"x-ms-client-name": "Expires", | ||
"type": "integer", | ||
"format": "int64", | ||
"description": "Expiry date in seconds since 1970-01-01T00:00:00Z." | ||
}, | ||
"created": { | ||
"type": "integer", | ||
"format": "int64", | ||
"readOnly": true, | ||
"description": "Creation time in seconds since 1970-01-01T00:00:00Z." | ||
}, | ||
"updated": { | ||
"type": "integer", | ||
"format": "int64", | ||
"readOnly": true, | ||
"description": "Last updated time in seconds since 1970-01-01T00:00:00Z." | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The format should be unixtime
unless that would be considered breaking. See
azure-rest-api-specs/specification/keyvault/data-plane/Microsoft.KeyVault/stable/7.2/common.json
Lines 10 to 42 in 5e455f9
"Attributes": { | |
"properties": { | |
"enabled": { | |
"type": "boolean", | |
"description": "Determines whether the object is enabled." | |
}, | |
"nbf": { | |
"x-ms-client-name": "NotBefore", | |
"type": "integer", | |
"format": "unixtime", | |
"description": "Not before date in UTC." | |
}, | |
"exp": { | |
"x-ms-client-name": "Expires", | |
"type": "integer", | |
"format": "unixtime", | |
"description": "Expiry date in UTC." | |
}, | |
"created": { | |
"type": "integer", | |
"format": "unixtime", | |
"readOnly": true, | |
"description": "Creation time in UTC." | |
}, | |
"updated": { | |
"type": "integer", | |
"format": "unixtime", | |
"readOnly": true, | |
"description": "Last updated time in UTC." | |
} | |
}, | |
"description": "The object attributes managed by the KeyVault service." | |
}, |
allOf
reference like we do in the data plane.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unixtime was indeed considered a breaking change, there was an old email thread about this. I'll see if I can dig it up
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The numeric representation should be the same anyway, or was it an issue because client code was generated differently?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see they were int64, already. Unfortunate, but I still think we should investigate fixing this because the numeric representation is the same.
Lines 382 to 405 in 5e455f9
"nbf": { | |
"x-ms-client-name": "NotBefore", | |
"type": "integer", | |
"format": "int64", | |
"description": "Not before date in seconds since 1970-01-01T00:00:00Z." | |
}, | |
"exp": { | |
"x-ms-client-name": "Expires", | |
"type": "integer", | |
"format": "int64", | |
"description": "Expiry date in seconds since 1970-01-01T00:00:00Z." | |
}, | |
"created": { | |
"type": "integer", | |
"format": "int64", | |
"readOnly": true, | |
"description": "Creation time in seconds since 1970-01-01T00:00:00Z." | |
}, | |
"updated": { | |
"type": "integer", | |
"format": "int64", | |
"readOnly": true, | |
"description": "Last updated time in seconds since 1970-01-01T00:00:00Z." | |
}, |
I'll change my PR vote, but I'd like to see a subsequent PR to use the same CloudError eventually from managedHsm.json.
...fication/keyvault/resource-manager/Microsoft.KeyVault/preview/2021-11-01-preview/common.json
Show resolved
Hide resolved
...tion/keyvault/resource-manager/Microsoft.KeyVault/preview/2021-11-01-preview/managedHsm.json
Show resolved
Hide resolved
…Vault to add version stable/2021-10-01 and preview/2021-11-01-preview (#2173) Create to sync Azure/azure-rest-api-specs#16156 [ReCreate this PR](https://github.com/azure-resource-manager-schemas/compare/main...AzureSDKAutomation:sdkAuto/keyvault?expand=1)
…stable/2021-10-01 and preview/2021-11-01-preview (Azure#16156) * Adds base for updating Microsoft.KeyVault from version preview/2021-06-01-preview to version 2021-10-01 * Updates readme * Updates API version in new specs and examples * Keys.json done * keyvault.json done * Readd systemdata * Fix keyvault.json * Add type: object to missing definitions except MHSMs. * Fix * Fix * Add type object to MHSM * Remove 404 responses from new api-version * Merge new preview version 2021-11-01-preview * Readd 2021-10-01 to readme * Add changes for key rotation to new preview api version. * Add x-ms-enum as per request from SDK team * Fix duplicated value
…stable/2021-10-01 and preview/2021-11-01-preview (Azure#16156) * Adds base for updating Microsoft.KeyVault from version preview/2021-06-01-preview to version 2021-10-01 * Updates readme * Updates API version in new specs and examples * Keys.json done * keyvault.json done * Readd systemdata * Fix keyvault.json * Add type: object to missing definitions except MHSMs. * Fix * Fix * Add type object to MHSM * Remove 404 responses from new api-version * Merge new preview version 2021-11-01-preview * Readd 2021-10-01 to readme * Add changes for key rotation to new preview api version. * Add x-ms-enum as per request from SDK team * Fix duplicated value
This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
Changelog
Add a changelog entry for this PR by answering the following questions:
Contribution checklist:
If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist
Otherwise your PR may be subject to ARM review requirements. Complete the following:
Check this box if any of the following apply to the PR so that label “WaitForARMFeedback” will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest.
-[ ] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits.
Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.
If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.
Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.