Skip to content

Conversation

@sonathan
Copy link
Contributor

@sonathan sonathan commented Jul 21, 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

@msftclas
Copy link

@sonathan,
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

@veronicagg veronicagg left a comment

Choose a reason for hiding this comment

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

Please review model validation errors in added example at https://travis-ci.org/Azure/azure-rest-api-specs/jobs/255998310#L661.
I understand you're not making changes in the rest of the spec, so just making sure you know about linter error/warnings being reported: https://travis-ci.org/Azure/azure-rest-api-specs/jobs/255998308#L674.
Thanks!

``` yaml
directive:
- suppress: DefinitionsPropertiesNamesCamelCase
reason: Autorest invalidates two letter acronyms as well and changes in data contracts require service wide changes and require more time
Copy link
Contributor

Choose a reason for hiding this comment

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

what do you mean by Autorest invalidates 2 letter acronyms as well?
Have you requested approval for this suppression already? Please refer to: https://github.com/Azure/adx-documentation-pr/wiki/Swagger-Validation-Errors-Suppression

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, we have requested approval for this supprestion already and also for the XmsExamplesProvidedValidation, as said by @ravbhatnagar that "As Samer said, we cant give an exception for the examples violation. This will not block the PR to be merged but it will be shown as a violation till it is fixed." we had a mail thread with [email protected], [email protected] with subject: Violations Suppression requested for PR 1139

Copy link
Contributor

Choose a reason for hiding this comment

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

@sonathan thanks for pointing this out. Regarding the specific violation DefinitionsPropertiesNamesCamelCase the justification in the email and the above doesn't seem to match the reason why the error is being reported. I see properties named as as "Provider" for "ClientDiscoveryDisplay", which violates the rule. I understand this is a breaking change and you may not want to take it right now, would this be a permanent exception? @ravbhatnagar @salameer

Copy link
Contributor

Choose a reason for hiding this comment

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

@sonathan - We cant add suppression for the camel casing violation. Till this is fixed, it will continue to show as violation.

}
},
"/Subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.RecoveryServices/operations": {
"/providers/Microsoft.RecoveryServices/operations": {
Copy link
Contributor

Choose a reason for hiding this comment

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

@ravbhatnagar FYI - fix that's a potential breaking change.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For this you can refer: #1267 CLI is not yet released and it will be including these changes.

Copy link
Contributor

Choose a reason for hiding this comment

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

@veronicagg - This fix is fine since otherwise the API had no meaning and clients couldnt anyway meaningfully use it. And as @sonathan pointed out, the CLI is not yet released so from that perspective it should be ok as well.

}
}
},
"/Subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.RecoveryServices/operations": {
Copy link
Contributor

Choose a reason for hiding this comment

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

subscriptionID and resourceGroupName are in the path parameters included below (line 65), please remove them if not applicable (https://travis-ci.org/Azure/azure-rest-api-specs/jobs/255998309#L685)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thankyou. Removing SubsId and ResourceGroupName from parameter from subsequent commit.

Copy link
Contributor

Choose a reason for hiding this comment

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

thanks, will take a look in your next commit.

``` yaml
directive:
- suppress: DefinitionsPropertiesNamesCamelCase
reason: Autorest invalidates two letter acronyms as well and changes in data contracts require service wide changes and require more time
Copy link
Contributor

Choose a reason for hiding this comment

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

@sonathan thanks for pointing this out. Regarding the specific violation DefinitionsPropertiesNamesCamelCase the justification in the email and the above doesn't seem to match the reason why the error is being reported. I see properties named as as "Provider" for "ClientDiscoveryDisplay", which violates the rule. I understand this is a breaking change and you may not want to take it right now, would this be a permanent exception? @ravbhatnagar @salameer

@veronicagg veronicagg added the WaitForARMFeedback <valid label in PR review process> add this label when ARM review is required label Jul 26, 2017
@ravbhatnagar
Copy link
Contributor

@veronicagg - As stated above, lets not add suppression for the camel case fix. It will remain a violation as the service team is expected to fix it.

@veronicagg
Copy link
Contributor

thanks @ravbhatnagar .
@sonathan please remove suppression that was added to the readme file, then I can approve this PR. thanks!

{
"name": "AzureBackupReport",
"displayName": "AzureBackup Reporting Data",
"blobDuration": "PT1H"
Copy link
Contributor

Choose a reason for hiding this comment

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

There is a remaining issue with the example model validation https://travis-ci.org/Azure/azure-rest-api-specs/jobs/259348817#L657
The value for blobDuration doesn't match the date-time format per https://xml2rfc.tools.ietf.org/public/rfc/html/rfc3339.html#anchor14
Please update these.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated. Thanks Veronica!

@veronicagg
Copy link
Contributor

@sonathan just let me know if you have questions about the issue pointed out above.

@sonathan
Copy link
Contributor Author

sonathan commented Aug 4, 2017

@veronicagg I have updated the examples.

Copy link
Contributor

@veronicagg veronicagg left a comment

Choose a reason for hiding this comment

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

questions inline

},
"blobDuration": {
"description": "Blob duration.",
"format": "date-time",
Copy link
Contributor

Choose a reason for hiding this comment

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

is the field really not a date-time?

},
"Origin": "user"
},
{
Copy link
Contributor

Choose a reason for hiding this comment

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

why did you decide to remove this part? It's good to include more and cover more fields, we need to make sure the wire matches what's in the swagger, that's the purpose of having the example covering more.

@ravbhatnagar
Copy link
Contributor

@veronicagg - I see the label indicating WaitForARMFeedback. Just wanted to confirm if anything is needed from my side on this.

@veronicagg
Copy link
Contributor

@ravbhatnagar no, you've commented on the suppression not being allowed above, and the label did not get removed then. I'll remove it now, next time, feel free to remove it after you provide your feedback. thanks!
On this PR I'm waiting on @sonathan regarding my questions on the examples.

@veronicagg veronicagg removed the WaitForARMFeedback <valid label in PR review process> add this label when ARM review is required label Aug 7, 2017
@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/recoveryservices/resource-manager/readme.md
Before the PR: Warning(s): 28 Error(s): 40
After the PR: Warning(s): 28 Error(s): 43

AutoRest Linter Guidelines | AutoRest Linter Issues

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

Thanks for your co-operation.

@sonathan
Copy link
Contributor Author

sonathan commented Aug 8, 2017

Hi @veronicagg

As we are in preview, and the contracts had changed in service side, I have updated those here and have also updated examples to cover out as much scenarios as possible.

"description": "Blob duration.",
"type": "string",
"readOnly": true
"description": "blob duration",
Copy link
Contributor

Choose a reason for hiding this comment

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

since this field is not specified as date-time, is there an enum that corresponds to it? How does the customer know what goes in there? The example has a value that looks quite arbitrary, therefore my question. thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi @veronicagg , As this field is in Response and Shoebox creates blobs in customer storage account every hour. The value PT1H indicates blobs per hour. Thanks!

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks @sonathan . Should this be part of its description? Are customers expected to know what it means, if so, how? thanks!

"type": "string"
}
}
},
Copy link
Contributor

Choose a reason for hiding this comment

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

FYI - Renaming of the model may cause a breaking change, if there were any SDKs released based on the prior spec.

"name": {
"description": "Name of the log.",
"type": "string",
"readOnly": true
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
}
},
"NextLink": {
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
Contributor Author

Choose a reason for hiding this comment

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

Thanks for pointing out.

"Name": {
"description": "Name of the operation.",
"type": "string",
"readOnly": true
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
Contributor Author

Choose a reason for hiding this comment

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

Thanks!

Copy link
Contributor

Choose a reason for hiding this comment

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

@sonathan it appears that this one is still showing up https://travis-ci.org/Azure/azure-rest-api-specs/jobs/262537716#L1457 therefore causing 1 more error in the Linter compared to the spec before this PR, you may want to update this one as well.

@veronicagg
Copy link
Contributor

@sonathan one more question, since you mentioned you're in preview...

  1. are the changes included in this spec deployed?
  2. is there a reason why your api-version is not updated or includes "preview" in it?

@sonathan
Copy link
Contributor Author

sonathan commented Aug 8, 2017

@veronicagg Yes the changes are already deployed. To be honest we have added this API only for compliance, whenever there is a need we refer to recoveryServicesBackup for this API.

@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/recoveryservices/resource-manager/readme.md
Before the PR: Warning(s): 28 Error(s): 40
After the PR: Warning(s): 28 Error(s): 41

AutoRest Linter Guidelines | AutoRest Linter Issues

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

Thanks for your co-operation.

Copy link
Contributor

@veronicagg veronicagg left a comment

Choose a reason for hiding this comment

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

Looks good, just one question left and one linter error that appears to not have been updated in the last commit.

@veronicagg
Copy link
Contributor

@sonathan if you have any questions about my last comment, please let me know, thanks.

@veronicagg
Copy link
Contributor

@sonathan any updates?

@veronicagg
Copy link
Contributor

@sonathan FYI - the PR will get closed in a few days if there's no activity from your side. It it gets closed, you may reopen it when you're back to it. Thanks!

@veronicagg
Copy link
Contributor

@sonathan This PR will get closed tomorrow, if no updates are received, thanks.

@veronicagg
Copy link
Contributor

@sonathan please reopen the PR and tag me when you're back to this, thanks.

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.

5 participants