-
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
Update the specification
directory structure article
#28464
Conversation
Next Steps to Merge✅ All automated merging requirements have been met! To get your PR merged, see aka.ms/azsdk/specreview/merge. |
Swagger Validation Report
|
Swagger Generation Artifacts
|
PR validation pipeline restarted successfully. If there is ApiView generated, it will be updated in this comment. |
documentation/directory-structure.md
Outdated
TypeSpec folders are `specification/playfab/Playfab`. | ||
`rpnamespace` names present are: `Microsoft.Automation` (in `automation` rp), `Microsoft.Batch` (in `batch` rp) and `Microsoft.Playfab` (in `playfab` rp). | ||
|
||
## Folder Structure for service groups |
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.
@JeffreyRichter @rkmanda I significantly shortened this section and added a note of this not being allowed going forward. Can you review?
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.
Lets setup a meeting and discuss.
documentation/directory-structure.md
Outdated
If TypeSpec sources are present, OpenAPI specs in the `resource-manager` | ||
and `data-plane` folders are generated from TypeSpec sources. | ||
|
||
## Resource provider namespace (`rpnamespace`) folders |
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.
Should this be higher in the list? before TypeSpec sources?
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 doc edited in this PR doesn't seem to currently take into account the following special case from the email thread
This probably means I should un-delete & update this part:
|
cc @josefree |
FYI @ladonnaq |
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.
Left some feedback but looks good to me overall.
To unblock the PR, as rkmanda doesn't have time to review it. I'll incorporate any feedback in a follow-up PR.
|
||
For example, [`specification/containerservice`] is a `service group` for both `aks` and `fleet` services. | ||
|
||
The doc for `aks` is [Azure Kubernetes Service]. It points to aks REST reference e.g. for [API version `2024-01-01`][aks REST reference 2024-01-01], |
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.
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.
It is indeed hyperlinked. I am using markdown reference links. It links to https://learn.microsoft.com/en-us/azure/aks/
|
||
Each `README.md` describes a single `service` and is used as an SDK package and documentation for each version of the service. | ||
Inside the `README.md` file there are lists of paths to OpenAPI spec `.json` files making up given service version. | ||
|
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 think we should describe specific requirements on the README.md here. For example, it should contain a "default" tag that refers to "current" version of the service (the ref docs depend on this).
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.
To avoid duplication I wanted to keep this section lightweight. But perhaps we should add it to https://aka.ms/azsdk/autorest.
Note this doc mentions:
Both the /resource-manager and /data-plane folders must contain an AutoRest configuration file, README.md. Learn more about this file at aka.ms/azsdk/autorest.
|
||
The `specification` folder is the root folder for all service specifications. | ||
|
||
Each child of the `specification` folder corresponds to a `service` specification for given Azure team. Here we denote such folder as `<azureTeam>`. |
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 think we should change all instances of "azureTeam" to "azureService". We should not "ship our organization structure" in our public API surface, but using "azureTeam" suggests that we do that.
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.
@mikekistler can you consult this with @JeffreyRichter ? My concern is that if we call it azureService
then we end up with conflicting terminology where an azureService
has inside it a serviceGroup
in some cases, which IMO is very counter-intuitive.
Link for easy review of the resulting document:
A follow-up to:
As I continue to work on overhauling our documentation.
This PR contributes to:
Notable changes:
service groups
and added a note we do not support new service group going forward, just existing ones.RE: Typespec questions
profile
. The repository hasprofile
andprofiles
folders but these directories appear to be legacy to me, untouched for 3 years.Additional notes:
spec family
for what in this article is called eitherresource provider
orservice group
. We should sort out this nomenclature.Re: Enforcing Unified API Versions in azure-rest-api-specs
Re: TypeSpecValidation and brownfield specs in RPSaaSMaster
Re: Preview specs in stable folder - wrong documentation?
RE: Typespec questions
TODOs: