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 CheckNameAvailability operation to 2017-05-01 Swagger (management plane) for Azure Batch #1432

Merged
merged 2 commits into from
Jul 20, 2017

Conversation

kiwidev
Copy link
Member

@kiwidev kiwidev commented Jul 17, 2017

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.

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

Note for reviewers

@msftclas
Copy link

@kiwidev,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

@matthchr
Copy link
Member

This looks good to me @kiwidev

@vishrutshah
Copy link
Contributor

Thanks @kiwidev for the PR. I'll be reviewing the PR by tomorrow. Feel free to ping me anytime if you need something meanwhile :)

@ravbhatnagar
Copy link
Contributor

#ARMSignedOff

Copy link
Contributor

@vishrutshah vishrutshah left a comment

Choose a reason for hiding this comment

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

@kiwidev Left some questions & comments. Let me know what you think. Thanks!

"tags": [
"Application"
],
"operationId": "Application_List",
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we name it as Application_ListByBatchAccount being applications as tracked resource?

"in": "body",
"required": true,
"schema": {
"$ref": "#/definitions/BatchAccountCreateParameters"
Copy link
Contributor

Choose a reason for hiding this comment

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

A PUT operation request body schema should be the same as its 200 response schema, to allow reusing the same entity between GET and PUT. If the schema of the PUT request body is a superset of the GET response body, make sure you have a PATCH operation to make the resource updatable. Operation: 'BatchAccount_Create' Request Model: 'BatchAccountCreateParameters' Response Model: 'BatchAccount'

Can you please look why is this not the case?

}
}
},
"/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Batch/batchAccounts/{accountName}/applications/{applicationId}/versions/{version}": {
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we not have ListByApplication operation for PATH

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Batch/batchAccounts/{accountName}/applications/{applicationId}/versions

Reference: https://travis-ci.org/Azure/azure-rest-api-specs/jobs/254658613#L673

"tags": [
"BatchAccount"
],
"operationId": "BatchAccount_Create",
Copy link
Contributor

Choose a reason for hiding this comment

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

As we use the NOUN part of NOUN_VERB pattern in operationId in the grouping of operation. Currently, we have a model named as NOUN that'll be auto resolved by autorest to resolve naming conflicts.

Reference: https://travis-ci.org/Azure/azure-rest-api-specs/jobs/254658613#L685

Please make sure that is what you expect in SDK or we need to make them differ here.

"tags": [
"ApplicationPackage"
],
"operationId": "ApplicationPackage_Activate",
Copy link
Contributor

Choose a reason for hiding this comment

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

As we use the NOUN part of NOUN_VERB pattern in operationId in the grouping of operation. Currently, we have a model named as NOUN that'll be auto resolved by autorest to resolve naming conflicts.

Reference: https://travis-ci.org/Azure/azure-rest-api-specs/jobs/254658613#L916

Please review 18 of these [OperationIdNounConflictingModelNames] warning in the build here

Please make sure that is what you expect in SDK or we need to make them differ here.

},
"description": "Parameters for adding an Application."
},
"Application": {
Copy link
Contributor

Choose a reason for hiding this comment

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

line 1284: @ravbhatnagar Can you please validate that this is expected?

Top level properties should be one of name, type, id, location, properties, tags, plan, sku, etag, managedBy, identity. Model definition 'Application' has extra properties ['displayName,packages,allowUpdates,defaultVersion']Top level properties should be one of name, type, id, location, properties, tags, plan, sku, etag, managedBy, identity. Model definition 'Application' has extra properties ['displayName,packages,allowUpdates,defaultVersion']

Reference: https://travis-ci.org/Azure/azure-rest-api-specs/jobs/254658613#L1010

},
"description": "Contains information about an application in a Batch account."
},
"ApplicationPackage": {
Copy link
Contributor

Choose a reason for hiding this comment

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

line 1312: @ravbhatnagar same as above. can you please validate?

Top level properties should be one of name, type, id, location, properties, tags, plan, sku, etag, managedBy, identity. Model definition 'ApplicationPackage' has extra properties ['version,state,format,storageUrl,storageUrlExpiry,lastActivationTime']

Reference: https://travis-ci.org/Azure/azure-rest-api-specs/jobs/254658613#L1021

Copy link
Member Author

Choose a reason for hiding this comment

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

This type doesn't match the ARM proxy specification and will be reworked in a future API version.

},
"description": "Parameters for adding an Application."
},
"Application": {
Copy link
Contributor

Choose a reason for hiding this comment

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

line 1284: looks like this is an ARM resource. This should have id, name & type as the readOnly.

Reference: https://travis-ci.org/Azure/azure-rest-api-specs/jobs/254658613#L1045

Copy link
Member Author

Choose a reason for hiding this comment

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

This type doesn't match the ARM proxy specification and will be reworked in a future API version.

},
"ApplicationPackage": {
"properties": {
"id": {
Copy link
Contributor

Choose a reason for hiding this comment

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

If this is a resource then are we missing name & type as readOnly ?

Copy link
Member Author

Choose a reason for hiding this comment

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

This type doesn't match the ARM proxy specification and will be reworked in a future API version.

@@ -0,0 +1,1618 @@
{
"swagger": "2.0",
Copy link
Contributor

Choose a reason for hiding this comment

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

This file is placed at the wrong location. Please move it inside the Batch specifications.

Copy link
Member Author

Choose a reason for hiding this comment

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

Oops, this file should not have been included, and has been removed. The diff was only on the BatchManagement.json file inside 2017-05-01. (Only change should be the checkNameAvailability changes).

@kiwidev
Copy link
Member Author

kiwidev commented Jul 19, 2017

@vishrutshah apologies, there was an extra file included in this commit which has now been removed. All of the issues you've pointed out are not changing as part of the PR, and they are mostly all known issues.
As part of the next API version we are planning to revisit the API surface, which will address all / most of these issues. Unfortunately, as these APIs have been in production for a while (in the case of applications since before the ARM spec was well defined for proxy resources) we're stuck with them in these API versions.

The intention of this PR was just to review the "checkNameAvailability" changes.

@vishrutshah
Copy link
Contributor

hahaah... thanks for removing that file. Let me review the smaller chunk now :)

@vishrutshah
Copy link
Contributor

Closing and re-opening this PR to have the latest CI changes to include CI bug fix.

@vishrutshah vishrutshah reopened this Jul 19, 2017
@msftclas
Copy link

@kiwidev,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

Copy link
Contributor

@vishrutshah vishrutshah left a comment

Choose a reason for hiding this comment

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

@kiwidev Left couple of minor comments. Let me know what you think? Thanks!

},
"type": {
"type": "string",
"description": "The resource type. Must be set to Microsoft.Batch/batchAccounts"
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

Changed, thanks.

"CheckNameAvailabilityResult": {
"properties": {
"nameAvailable": {
"type": "boolean",
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this be readOnly: true as seems like only settable by server

Copy link
Member Author

Choose a reason for hiding this comment

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

Changed.

},
"description": "Gets the reason that a Batch account name could not be used. The Reason element is only returned if NameAvailable is false."
},
"message": {
Copy link
Contributor

Choose a reason for hiding this comment

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

readOnly: true here as well ?

Copy link
Member Author

Choose a reason for hiding this comment

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

Changed

@kiwidev
Copy link
Member Author

kiwidev commented Jul 19, 2017

Thanks @vishrutshah, changes made as noted.

@azuresdkciprbot
Copy link

Hi There,

I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:

File: specification/batch/resource-manager/readme.md
Before the PR: Warning(s): 26 Error(s): 14
After the PR: Warning(s): 27 Error(s): 14

AutoRest Linter Guidelines | AutoRest Linter Issues

Send feedback and make AutoRest Linter Azure Bot smarter day by day!

Thanks for your co-operation.

@kiwidev
Copy link
Member Author

kiwidev commented Jul 19, 2017

@vishrutshah is the build error on the ruby build: ValueError: Autorest call ended with 0, but no files were generated actually a build error or a bug in the CI system that we can work around? Thanks.

@vishrutshah
Copy link
Contributor

@kiwidev It's because of the wrong swagger_to_sdk config file in Ruby repo. We should be good to move forward here.

Issue Azure/azure-sdk-for-ruby#853

@vishrutshah
Copy link
Contributor

looks like model validation failing but seems like that already existed.

BatchAccount_Delete: RESPONSE_STATUS_CODE_NOT_IN_EXAMPLE Reference: https://travis-ci.org/Azure/azure-rest-api-specs/jobs/255449011#L662

Would you mind fixing this by adding 204 in example or we can open an issue for the service team to follow up. I am fine both the ways. Let me know. Thanks!

@kiwidev
Copy link
Member Author

kiwidev commented Jul 19, 2017

I'll make the change as part of this PR.

@azuresdkciprbot
Copy link

Hi There,

I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:

File: specification/batch/resource-manager/readme.md
Before the PR: Warning(s): 26 Error(s): 14
After the PR: Warning(s): 27 Error(s): 14

AutoRest Linter Guidelines | AutoRest Linter Issues

Send feedback and make AutoRest Linter Azure Bot smarter day by day!

Thanks for your co-operation.

@kiwidev
Copy link
Member Author

kiwidev commented Jul 19, 2017

@vishrutshah Change made to add 204 to the example, model validation now passing.

@vishrutshah vishrutshah merged commit 1183158 into Azure:current Jul 20, 2017
@vishrutshah
Copy link
Contributor

Thanks @kiwidev for the quick turn-around! 👍

@AutorestCI
Copy link

No modification for AutorestCI/azure-sdk-for-node

@AutorestCI
Copy link

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

Successfully merging this pull request may close these issues.

7 participants