Skip to content

Removed no longer supported SQL resource types and renamed several operations#1005

Merged
veronicagg merged 46 commits intoAzure:masterfrom
jaredmoo:breakingchanges
Mar 17, 2017
Merged

Removed no longer supported SQL resource types and renamed several operations#1005
veronicagg merged 46 commits intoAzure:masterfrom
jaredmoo:breakingchanges

Conversation

@jaredmoo
Copy link
Contributor

@jaredmoo jaredmoo commented Mar 7, 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

  • I have read the contribution guidelines.
  • My spec meets the review criteria:
    • The spec conforms to the Swagger 2.0 specification.
    • Validation errors from the Linter extension for VS Code have all been fixed for this spec. (Note: for large, previously checked in specs, there will likely be many errors shown. Please contact our team so we can set a timeframe for fixing these errors if your PR is not going to address them).
    • The spec follows the patterns described in the Swagger good patterns document unless the service API makes this impossible.

jaredmoo added 3 commits March 6, 2017 17:36
These APIs were used to upgrade servers from v2 to v12. This is no longer applicable because all servers are v12.
Same for ElasticPoolEditions. Enum names should be singular.
@msftclas
Copy link

msftclas commented Mar 7, 2017

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

@jaredmoo
Copy link
Contributor Author

jaredmoo commented Mar 7, 2017

Clarification: I actually removed inaccessible or no longer supported types, not APIs. The enum rename is included to get breaking changes done all together.

@jaredmoo jaredmoo changed the title Removed no longer supported SQL APIs Removed no longer supported SQL resource types Mar 7, 2017
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.

Thanks @jaredmoo Your changes look good to me, I've labeled this PR as "potential-sdk-breaking-changes".
There are other errors listed by our validation tool, not related to the changes in this PR, would you like to take a look at those as part of this PR?

@jaredmoo
Copy link
Contributor Author

jaredmoo commented Mar 7, 2017

Thanks @veronicagg , I assume you're talking about the following checks that have PR_ONLY = TRUE?
https://travis-ci.org/Azure/azure-rest-api-specs/jobs/208461582
https://travis-ci.org/Azure/azure-rest-api-specs/jobs/208461584

@jaredmoo
Copy link
Contributor Author

jaredmoo commented Mar 7, 2017

I believe we are waiting on you guys to make changes to the examples validation, so I will just focus on the linter errors ( https://travis-ci.org/Azure/azure-rest-api-specs/jobs/208461582 )

@jaredmoo
Copy link
Contributor Author

jaredmoo commented Mar 7, 2017

Comments on errors:

  • ListByOperationsValidation: I believe the existing names are correct and we should silence these warnings somehow.
  • ProvidersPathValidation: in these case current is a singleton, I'm interested in your guidance on this. Should we make it a {param} with only one allowed value (current?)
  • BodyTopLevelProperties: isn't kind a standard property? Either way this property is what the API has which can't be changed
  • ArmResourcePropertiesBag: I don't understand what this is saying. It sounds like it's complaining that we are replacing the base properties with our own properties. Can you clarify how to fix this?
  • BooleanPropertyNotRecommended, GuidValidation, DefinitionsPropertiesNamesCamelCase: This is what the API does, I can't change that. We should silence these warnings.
  • TrackedResourceValidation: Let me check if this is actually a tracked resource.
  • TrackedResourcePatchOperationValidation: Understood, I believe patch is already supported. Will investigate.

This is the output of latest version of AutoRest that I'm looking at, right?

@veronicagg
Copy link
Contributor

@jaredmoo Regarding linter errors:

  1. ListByOperationsValidation - I agree.
  2. ProvidersPathValidation - Yes, so the recommendation would be to add a parameter, and make it an enum with 1 value (https://github.com/Azure/azure-rest-api-specs/blob/master/documentation/swagger-extensions.md#single-value-enum-as-a-constant)
  3. BodyTopLevelProperties - Ok, @ravbhatnagar is kind a standard property?
  4. ArmResourcePropertiesBag - ignore this one for now, we've temporarily removed this rule, as it needs modifications
  5. BooleanPropertyNotRecommended, GuidValidation, DefinitionsPropertiesNamesCamelCase - Ok, let's keep it as is for now.
  6. TrackedResouceValidation - sounds good
  7. TrackedResourcePatchOperationValidation - sounds good

Regarding model validation errors:

Thanks!

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 take a look at my previous comment and let me know if you have additional questions. Thanks!

@jaredmoo
Copy link
Contributor Author

jaredmoo commented Mar 8, 2017

Done. System2 is actually correct, I had removed this enum element previous because I thought it was wrong.

@jaredmoo
Copy link
Contributor Author

jaredmoo commented Mar 8, 2017

Will there be a way of suppressing these errors that are acceptable? That way in the future it will be easier to catch regressions.

Copy link
Contributor

@anudeepsharma anudeepsharma left a comment

Choose a reason for hiding this comment

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

LGTM

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.

Left one more comment inline, that's giving an error during semantic validation.
Regarding the "exceptions", yes, we will have a way to suppress them in the future, we're working on improving the tools to support that.
Regarding the remaining errors:

  • What did you find out on the TrackedResource checks?
  • BodyTopLevelProperties - kind is a standard property and we'll be correcting the rule

Since the latest changes introduced "importExport.json" to the PR, you may want to take a look at validation failures:
https://travis-ci.org/Azure/azure-rest-api-specs/jobs/209193852#L964

"type": "string",
"description": "The name of the database for which setting the transparent data encryption applies."
},
{
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.

Fixed in 7cf6aee

@jaredmoo
Copy link
Contributor Author

jaredmoo commented Mar 9, 2017

@jaredmoo
Copy link
Contributor Author

jaredmoo commented Mar 9, 2017

What do I do about this one? https://travis-ci.org/Azure/azure-rest-api-specs/jobs/209193852#L980

We already have /providers/Microsoft.Sql/operations defined in sql.core.json.

@jaredmoo
Copy link
Contributor Author

We have some proxy resources that don't have a type property. IMO this is an API bug, but for Swagger purposes right now should I have them include ProxyResource, or make my own model type e.g. SubResource which has just id and name?

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.

Regarding your question on "ProxyResource" versus "SubResource", since you're referencing your own definitions right now, you can create your own.
Regarding the enum mismatch from a previous comment, I'd recommend updating the spec to make it a "string" and include in the description what the possible values are and how to construct the string, not sure if they are comma separated or semicolon separated, and also, is there a semicolon at the end? When the API bug gets fixed, then this could be turned into an array type.

@@ -0,0 +1,271 @@
{
"definitions":{
"Resource":{
Copy link
Contributor

Choose a reason for hiding this comment

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

missing "x-ms-azure-resource": true

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

}
]
},
"ResourceModelWithAllowedPropertySet":{
Copy link
Contributor

Choose a reason for hiding this comment

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

missing "x-ms-azure-resource": true?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed this model (unused)

]
}
},
"parameters":{
Copy link
Contributor

Choose a reason for hiding this comment

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

are you referring to these parameters anywhere?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, removed

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was just copying resourceDefinitions.json from Azure/azure-rest-api-specs-pr#40 since I thought that's what you were asking for.

@@ -0,0 +1,271 @@
{
Copy link
Contributor

Choose a reason for hiding this comment

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

you could include these definitions in one of your existing files and have others refer to them, having a separate file will, at this time, produce "many" violations, since this swagger file is not following an RP structure. At some point, our tools would account for this separate files.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok. I misunderstood what you said earlier. Done.

Resource is back to being defined in each spec file.

Also improved some operation descriptions.
@jaredmoo
Copy link
Contributor Author

Changed that enum to a regular string. It's semicolon separated, description was wrong.

@veronicagg
Copy link
Contributor

Thanks @jaredmoo .
Regarding the resource definitions, if they are shared among your own files, you could have them just in one of those, and refer to the ones in that one from the others. It's also fine if you want to keep it this way.
From the latest validations, have you looked into the following?

@jaredmoo
Copy link
Contributor Author

https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211678413#L935 - false positive. DatabaseSecurityAlertPolicy has location, but it's not required, so it's not a tracked resource.

https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211678413#L1060 - unfortunately the API already uses guid in production, I can't change it

https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211678413#L1239 - issue #1018 

Resolving merge conflicts and removing resource definitions from all files except sql.core
https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211678413#L1250 - issue #1018

https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211678413#L1272 - unfortunately the API already uses guid in production, I can't change it

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.

Changes look good, thanks!

@veronicagg veronicagg merged commit ea48f56 into Azure:master Mar 17, 2017
@AutorestCI
Copy link

No modification for NodeJS

@AutorestCI
Copy link

@AutorestCI
Copy link

@jaredmoo jaredmoo deleted the breakingchanges branch July 8, 2017 17:21
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