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

[Key Vault] TypeSpec for Security Domain library #31060

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

mccoyp
Copy link
Member

@mccoyp mccoyp commented Oct 16, 2024

Data Plane API Specification Update Pull Request

Tip

Overwhelmed by all this guidance? See the Getting help section at the bottom of this PR description.

This converts the existing Security Domain specification from Swagger to TypeSpec. The goal is to generate a Python library from this specification, azure-keyvault-securitydomain, for CLI consumption and external customer use. There are currently no plans for shipping this library in other languages.

Initial preview timeline: Python public preview release by October 22nd, 2024.

Python library implementation: Azure/azure-sdk-for-python#37929

PR review workflow diagram

Please understand this diagram before proceeding. It explains how to get your PR approved & merged.

spec_pr_review_workflow_diagram

API Info: The Basics

Most of the information about your service should be captured in the issue that serves as your API Spec engagement record.

  • Link to API Spec engagement record issue:

Is this review for (select one):

  • a private preview
  • a public preview
  • GA release

Change Scope

This section will help us focus on the specific parts of your API that are new or have been modified.
Please share a link to the design document for the new APIs, a link to the previous API Spec document (if applicable), and the root paths that have been updated.

Viewing API changes

For convenient view of the API changes made by this PR, refer to the URLs provided in the table
in the Generated ApiView comment added to this PR. You can use ApiView to show API versions diff.

Suppressing failures

If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the
Swagger-Suppression-Process
to get approval.

❔Got questions? Need additional info?? We are here to help!

Contact us!

The Azure API Review Board is dedicated to helping you create amazing APIs. You can read about our mission and learn more about our process on our wiki.

Click here for links to tools, specs, guidelines & other good stuff

Tooling

Guidelines & Specifications

Helpful Links

Getting help

  • First, please carefully read through this PR description, from top to bottom.
  • If you don't have permissions to remove or add labels to the PR, request write access per aka.ms/azsdk/access#request-access-to-rest-api-or-sdk-repositories
  • To understand what you must do next to merge this PR, see the Next Steps to Merge comment. It will appear within few minutes of submitting this PR and will continue to be up-to-date with current PR state.
  • For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure
    and https://aka.ms/ci-fix.
  • If the PR CI checks appear to be stuck in queued state, please add a comment with contents /azp run.
    This should result in a new comment denoting a PR validation pipeline has started and the checks should be updated after few minutes.
  • If the help provided by the previous points is not enough, post to https://aka.ms/azsdk/support/specreview-channel and link to this PR.

@mccoyp mccoyp added KeyVault TypeSpec Authored with TypeSpec labels Oct 16, 2024
Copy link

openapi-pipeline-app bot commented Oct 16, 2024

Next Steps to Merge

Next steps that must be taken to merge this PR:
  • ❌ This is the public specs repo main branch which is not intended for iterative development.
    You must acknowledge that you understand that after this PR is merged, you won't be able to stop your changes from being published to Azure customers.
    If this is what you intend, add PublishToCustomers label to your PR.
    Otherwise, retarget this PR onto a feature branch, i.e. with prefix release- (see aka.ms/azsdk/api-versions#release--branches).
  • ❌ This PR has at least one change violating Azure versioning policy (label: VersioningReviewRequired).
    To unblock this PR, either a) introduce a new API version with these changes instead of modifying an existing API version, or b) follow the process at aka.ms/brch.
  • ❌ The required check named TypeSpec Validation has failed. Refer to the check in the PR's 'Checks' tab for details on how to fix it and consult the aka.ms/ci-fix guide

Copy link

openapi-pipeline-app bot commented Oct 16, 2024

Generated ApiView

Language Package Name ApiView Link
TypeSpec Security.KeyVault.SecurityDomain https://apiview.dev/Assemblies/Review/0529655b61bc404ebd37d2d5192ba45a?revisionId=5ac0b2c595064cfda791f50d9ad46d3e

@AzureRestAPISpecReview AzureRestAPISpecReview added data-plane VersioningReviewRequired <valid label in PR review process>add this label when versioning review is required labels Oct 16, 2024
Copy link
Member

@heaths heaths left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apart from a few non-blocking thoughts, as long as the emitted swagger matches their service definition this looks good to me. Best to have Key Vault check over the swagger, though, or did you already generate a Python SDK from it to test against their service (probably best anyway)?

emitter-output-dir: "{project-root}/.."
output-file: "{azure-resource-provider-folder}/{service-name}/{version-status}/{version}/securitydomain-sdk.json"
# Uncomment this line and add "@azure-tools/typespec-python" to your package.json to generate Python code
"@azure-tools/typespec-python":
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this need to be up in the emit array as well, or is that only for the python SDK repo?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are these files ending in "-sdk"? They are for the service which we don't consider an "SDK" typically. Can't it just be "securitydomain.json"? This also matches what service swaggers are now for Key Vault, and what all the other TSPs should be doing.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added -sdk for this and the other conversions' swaggers because it's not totally aligned with the original swaggers. In this case, the Security Domain spec is constructed from common.json and securitydomain.json, so the swagger generated from it is the combination of those two

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's fine. common.json was also an implementation detail anyway and was just for humans to avoid duplication. Given we're emitting these swaggers, I don't see a need to differentiate. I worry that "sdk" will make orgs that want to generate their own clients (from swagger) think these aren't the service specs.

statusDetails?: string;
}

/**
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These appear to be normal Azure Core errors. Can't we use those instead of redefining?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Key Vault error is a little different in its definition, but I do think it's functionally equivalent to the Azure Core error. If I'm not mistaken, KV's custom error has an additional innerError property.

/**
* A JSON Web Key (JWK) for use in a security domain operation.
*/
model SecurityDomainJsonWebKey {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: seems we should be defining common types like JWKs in a common tsp further up. I won't block on this, but we should consider it. We don't want JWKs - an industry standard - diverging accidentally or incidentally.

* X509 certificate SHA1 thumbprint. This is optional.
*/
@encodedName("application/json", "x5t")
x5T?: string;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems this should be x5t just as it is below (x5tS256). That's the industry standard anyway, and won't impact casing rules in client emitters anyway...or shouldn't, anyway.

@@ -26,6 +26,7 @@ interface HsmSecurityDomain {
*/
#suppress "@azure-tools/typespec-azure-core/use-standard-operations" "Foundations.Operation necessary for Key Vault"
@pollingOperation(HsmSecurityDomain.downloadPending)
@finalOperation(HsmSecurityDomain.downloadPending)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems the operation ID should be case-sensitive, so we should either call the interface HSMSecurityDomain or use a decorator to do so, if possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
data-plane KeyVault PipelineBotTrigger TypeSpec Authored with TypeSpec VersioningReviewRequired <valid label in PR review process>add this label when versioning review is required
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants