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

[AKS] add POST endpoint for fetching accessProfiles #3098

Merged
merged 5 commits into from
May 21, 2018

Conversation

mboersma
Copy link
Member

@mboersma mboersma commented May 18, 2018

Adds a new POST endpoint that is preferred to GET for fetching AKS access profiles (Kubernetes configs). The endpoint is already deployed to RPs in all AKS regions.

I've tested this with the Python SDK and simple CLI changes that are needed and it works well.

cc: @weinong @shrutir25 @rjtsdl @sauryadas

PR information

  • The title of the PR is clear and informative.
  • There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
  • Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
  • If applicable, the PR references the bug/issue that it fixes.
  • Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

@AutorestCI
Copy link

AutorestCI commented May 18, 2018

Automation for azure-sdk-for-python

The initial PR has been merged into your service PR:
Azure/azure-sdk-for-python#2186

@AutorestCI
Copy link

AutorestCI commented May 18, 2018

Automation for azure-sdk-for-node

The initial PR has been merged into your service PR:
Azure/azure-sdk-for-node#2848

@AutorestCI
Copy link

AutorestCI commented May 18, 2018

Automation for azure-libraries-for-java

The initial PR has been merged into your service PR:
AutorestCI/azure-libraries-for-java#174

@AutorestCI
Copy link

AutorestCI commented May 18, 2018

Automation for azure-sdk-for-go

The initial PR has been merged into your service PR:
Azure/azure-sdk-for-go#1881

@@ -154,6 +154,58 @@
}
}
},
"/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ContainerService/managedClusters/{resourceName}/accessProfiles/{roleName}/listCredential": {
"post": {
Copy link
Member

Choose a reason for hiding this comment

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

@mboersma If this operation is preferred to ManagedClusters_GetAccessProfiles, you should declare it as deprecated (deprecated: True and update the description to say something generic like "Use ListCredential instead").

Copy link
Member Author

Choose a reason for hiding this comment

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

@lmazuel done.

Copy link
Contributor

@hovsepm hovsepm left a comment

Choose a reason for hiding this comment

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

Operation name with prefix List assumes multiple return values in array. You already have "operationId": "ManagedClusters_GetAccessProfiles", which returns exactly the same type ManagedClusterAccessProfile. then what is a point to add this new endpoint with such a confusing method name?

@mboersma
Copy link
Member Author

what is a point to add this new endpoint with such a confusing method name?

@hovsepm I was just using the name defined for the endpoint in the AKS RP. I agree it's not good terminology though. We can call it something different in the swagger if that's preferable. The idea here is we'd prefer POST to GET for this sensitive endpoint.

@weinong anything to add?

@hovsepm
Copy link
Contributor

hovsepm commented May 18, 2018

@mboersma yes please change the operation name. it is used to generate a method names in the SDKs in each language. Name should be self descriptive and discoverable. Please also revise the description because now for this 2 exposed operations

...
"operationId": "ManagedClusters_ListCredential",
"description": "Gets the accessProfile for the specified role name of the managed cluster with a specified resource group and name."
...
"operationId": "ManagedClusters_GetAccessProfiles"
"description": "Gets the accessProfile for the specified role name of the managed cluster with a specified resource group and name."

as a user of the generated SDK - how should I understand which method to call? What is the difference between them?

@@ -116,7 +116,8 @@
],
"operationId": "ManagedClusters_GetUpgradeProfile",
"summary": "Gets upgrade profile for a managed cluster.",
"description": "Gets the details of the upgrade profile for a managed cluster with a specified resource group and name.",
"deprecated": true,
"description": "Use ManagedClusters_ListCredential instead.",
Copy link
Contributor

Choose a reason for hiding this comment

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

I think you are deprecating the wrong operation. I believe you should deprecate operationId ManagedClusters_GetAccessProfiles, right?

Copy link
Member Author

Choose a reason for hiding this comment

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

D'oh, my mistake. I'll fix.

@hovsepm
Copy link
Contributor

hovsepm commented May 21, 2018

@mboersma I'll merge this PR however there is an issue that needs to be fixed for each endpoint. Please take a look to #3113

@hovsepm hovsepm merged commit 37e2f7b into Azure:master May 21, 2018
@tombuildsstuff
Copy link
Contributor

@mboersma 👋 out of interest, is there a timeframe for deprecating the old (GET) endpoint?

@mboersma mboersma deleted the aks-list-credential branch May 22, 2018 19:34
@mboersma
Copy link
Member Author

@tombuildsstuff once this change makes it into the az CLI, we plan to start returning a (useful) error from the GET endpoint 14 days afterward. So most likely that means two weeks after June 5. Let me know if that's going to cause problems!

@tombuildsstuff
Copy link
Contributor

@mboersma given that won't be available in the Go SDK until around that date, I don't feel that's a long enough period for deprecation IMO - we (Terraform) expose these values on our AKS resources, which we consume via the Azure SDK for Go. Whilst we're probably able to time a release shortly after this change goes live - however we should give users some time to update to the new version which uses Post instead of Get.

As such - would it be possible for the old endpoint to continue working until the start of July? Whilst I can understand this isn't ideal from your side, I think it's better to not break users workflows without a couple of weeks extra transition period for downstream dependencies once the SDK's are out :)

Thanks!

@tombuildsstuff
Copy link
Contributor

cc @joshgav / @marstr / @jhendrixMSFT :)

@mboersma
Copy link
Member Author

I don't feel that's a long enough period for deprecation IMO

Honestly, I don't think that's long enough either, I'm just reporting the current intent. I'll bring your feedback to the team and see if we can make the deprecation timeline more humane.

@tombuildsstuff
Copy link
Contributor

@mboersma awesome, thanks :)

@mboersma
Copy link
Member Author

mboersma commented Jun 1, 2018

@tombuildsstuff we will comply with the standard Azure deprecation policy and keep the GET endpoint functional for 12 more months. (We got similar feedback from ARM review on the newer API in #3131.)

@tombuildsstuff
Copy link
Contributor

@mboersma that's awesome, thanks so much :)

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

Successfully merging this pull request may close these issues.

5 participants