Skip to content

Add redis firewallRules to swagger specs w/ examples. (+minor descrip…#989

Merged
veronicagg merged 6 commits intoAzure:masterfrom
TimLovellSmith:firewallRules3
Mar 14, 2017
Merged

Add redis firewallRules to swagger specs w/ examples. (+minor descrip…#989
veronicagg merged 6 commits intoAzure:masterfrom
TimLovellSmith:firewallRules3

Conversation

@TimLovellSmith
Copy link
Copy Markdown
Member

@TimLovellSmith TimLovellSmith commented Mar 3, 2017

…tive changes to existing APIs).
(Reissue of PR #977 to get around CI issues...)

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.

@TimLovellSmith
Copy link
Copy Markdown
Member Author

(Please assign this to @veronicagg who had #977!)

@TimLovellSmith
Copy link
Copy Markdown
Member Author

@veronicagg It looks like there is some problem with the CI installing/running autorest for node.js?

@TimLovellSmith
Copy link
Copy Markdown
Member Author

@veronicagg
I couldn't figure this message from https://travis-ci.org/Azure/azure-rest-api-specs/jobs/207499990 out

  1. Azure swagger model validation using x-ms-examples and examples in spec /home/travis/build/Azure/azure-rest-api-specs/arm-redis/2016-04-01/swagger/redis.json should have valid examples.:

3360 ReferenceError: error is not defined

3361 at SpecValidator.validateRequest (node_modules/openapi-validation-tools/lib/specValidator.js:567:79)

3362 at SpecValidator.validateXmsExamples (node_modules/openapi-validation-tools/lib/specValidator.js:470:60)

3363 at SpecValidator.validateOperation (node_modules/openapi-validation-tools/lib/specValidator.js:412:10)

3364 at SpecValidator.validateOperations (node_modules/openapi-validation-tools/lib/specValidator.js:446:12)

3365 at node_modules/openapi-validation-tools/validate.js:86:15

@TimLovellSmith
Copy link
Copy Markdown
Member Author

Still getting a cryptic build error after fixing parameter names.
Shouldn't need to be tagged cla-required for me...

@amarzavery
Copy link
Copy Markdown
Contributor

The github CLA bot does not like you :(. It does the same with me many times :(

Comment thread arm-redis/2016-04-01/swagger/redis.json Outdated
}
}
},
"/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Cache/Redis/{cacheName}/firewallRules/": {
Copy link
Copy Markdown
Contributor

@amarzavery amarzavery Mar 4, 2017

Choose a reason for hiding this comment

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

I think there is an extra slash in the end that shouldn't be there, correct ?
"/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Cache/Redis/{cacheName}/firewallRules /":

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

@amarzavery thanks for spotting that!

@TimLovellSmith
Copy link
Copy Markdown
Member Author

@amarzavery What should I do about the CLA issue? Node SDK generation failure is opaque. I also see a lot of linter errors which seem to be extraneous to the content of the specific PR, I think they are caused by improvements to the linter - are any of those going to be blockers for this?

@TimLovellSmith
Copy link
Copy Markdown
Member Author

@veronicagg any advice on how to deal with the linter errors here?

Copy link
Copy Markdown
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.

@TimLovellSmith I made some comments inline related to linter errors. And here are some comments for the others:
Is there an operations API you can expose for the service? This error https://travis-ci.org/Azure/azure-rest-api-specs/jobs/208317608#L979 comes from a request from the ARM team to have an operation in the spec that lists all the available operations, like: https://github.com/Azure/azure-rest-api-specs/blob/master/arm-cdn/2016-10-02/swagger/cdn.json#L1578

I'm following up on errors with code "ArmResourcePropertiesBag", as I believe the rule may not be appropriate for those cases. (https://travis-ci.org/Azure/azure-rest-api-specs/jobs/208317608#L1001)

Even though, this issue is not caused by this PR, please take a look at https://travis-ci.org/Azure/azure-rest-api-specs/jobs/208317608#L1090

Comment thread arm-redis/2016-04-01/swagger/redis.json Outdated
"Redis",
"FirewallRules"
],
"operationId": "RedisFirewallRules_List",
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Is there a reason why the operation is named RedisFirewallRules_List? To follow the convention, based on our latest rules: "Operation RedisFirewallRules_List must be one of: firewallrules_listbysubscriptionid, firewallrules_list, firewallrules_listbyresourcegroup, firewallrules_listbyredis" (see ahttps://travis-ci.org/Azure/azure-rest-api-specs/jobs/208317608#L968), naming this operation "FirewallRules_List" would fix the issue.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

@veronicagg The naming guidance seems a little arbitrary. E.g. We call the create operation RedisFirewallRule_CreateOrUpdate and there's no error for that? (Or I overlooked it)

}
}
},
"/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Cache/Redis/{name}/patchSchedules/default": {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

https://travis-ci.org/Azure/azure-rest-api-specs/jobs/208317608#L990
The recommendation would be to follow the pattern /typename1/{typename1type}/typename2/{typename2type} after the namespace in the path. In this case, it's complaining because of "default" at the end. This could be resolved by replacing "default" with a {property} and have the property as part of the parameters, you could define it as an enum with one value "default" which would produce a similar result.

@TimLovellSmith
Copy link
Copy Markdown
Member Author

@veronicagg What contexts will humans be exposed to the operation name FirewallRules_List/firewallrulesListByRedis in? Do operation names have to be globally unique for any reason (e.g. using as programmatic ID)? The latter is not an intuitive name, so I'd prefer FirewallRules_List if possible, I just want to make sure there's no extra constraints...

@TimLovellSmith
Copy link
Copy Markdown
Member Author

TimLovellSmith commented Mar 7, 2017

@veronicagg I've made the change with patchSchedules 'default' as enum - I do still have a worry here that this might have been overvalidation - as it might end up making the actual generated sdk client more confusing to have to specify an enumeration with a single value... but we can wait to preview what sdk changes would result.

@TimLovellSmith
Copy link
Copy Markdown
Member Author

@veronicagg
Re: I've made the change with patchSchedules 'default' as enum" - now it seems to just fail model validation even worse... I think I made the required changes to examples here though.

{ code: 'REQUEST_VALIDATION_ERROR',
  message: 'Found errors in validating the request for x-ms-example "RedisCachePatchSchedulesGet" in operation "PatchSchedules_Get".',
  innerErrors: 
   [ { code: 'REQUIRED_PARAMETER_EXAMPLE_NOT_FOUND',
       message: 'In operation "PatchSchedules_Get", parameter name is required in the swagger spec but is not present in the provided example parameter values.' } ] }
{ AssertionError: swagger "arm-redis/2016-04-01/swagger/redis.json" contains model validation errors.
    at /home/travis/build/Azure/azure-rest-api-specs/test/model.js:21:14
  name: 'AssertionError',
  actual: false,
  expected: true,
  operator: '==',
  message: 'swagger "arm-redis/2016-04-01/swagger/redis.json" contains model validation errors.',
  generatedMessage: false }
    1) arm-redis/2016-04-01/swagger/redis.json should have valid examples.

@TimLovellSmith
Copy link
Copy Markdown
Member Author

@veronicagg No, my bad, I didn't update parameter set for all METHODs.

@veronicagg
Copy link
Copy Markdown
Contributor

@TimLovellSmith for your fist question "FirewallRules_List" looks good, the operation id is used in the method name in the SDK.
Regarding the parameter/enum question, see https://github.com/Azure/azure-rest-api-specs/blob/master/documentation/swagger-extensions.md#single-value-enum-as-a-constant

…ist' for what we hope will be nicer method naming.
@TimLovellSmith
Copy link
Copy Markdown
Member Author

@veronicagg Thanks for the answers! I'll change it to FirewallRules_List then, and bring back the patchSchedules/default change.

@TimLovellSmith
Copy link
Copy Markdown
Member Author

@veronicagg So I think I've fixed all the important feedbacks and linter errors. However, node SDK build job still seems to be failing in TravisCI - and outputting usage instructions instead of an actual error!? Could you please check on that?

@veronicagg
Copy link
Copy Markdown
Contributor

@TimLovellSmith we're working on fixing the CI failure that you're seeing, we expect to have that working today.
Changes look good, are you planning on fixing this one too?

Thanks!

@TimLovellSmith
Copy link
Copy Markdown
Member Author

@veronicagg No, I was not planning to address that as part of this PR. Is there an easy way to define the operations API without having to define the entire operation operations body shape in our redis.json? It's rather a lot of declarations to add, and I would think usually every RP implements the same contract.

@veronicagg
Copy link
Copy Markdown
Contributor

veronicagg commented Mar 11, 2017

@TimLovellSmith There seem to still be issues with CI, not just yours, so I've pinged someone else on that. I'll restart this job in case it helps anyway.
Regarding the OperationAPI: does the way that CDN defines it not work well for yours? What type of "easier" way would you be looking for in this case?
One more comment, after chatting with @ravbhatnagar a bit more, our validation for ProvidersPathValidation is a bit too strict and defining a parameter as a constant is not required, so you can leave it as is, or revert back to having the value in the path at https://github.com/Azure/azure-rest-api-specs/pull/989/files#diff-785771b0c72c01e60191a5d798d6d508R755; we'll be updating our validation tool to account for this soon.

@TimLovellSmith
Copy link
Copy Markdown
Member Author

@veronicagg Re "Operations" api, I think I was hoping for something like "Resource" such that every RP definition can link to one common definition, since they should all follow the same basic contract. Although yes, "Resource" is in our spec too...

@veronicagg
Copy link
Copy Markdown
Contributor

@TimLovellSmith ah, yes, I believe you're asking for https://github.com/Azure/azure-rest-api-specs-pr/pull/40, it's coming, at which point you'll be able to point to the common definition.

@TimLovellSmith
Copy link
Copy Markdown
Member Author

TimLovellSmith commented Mar 14, 2017

@veronicagg I had a look at pull/40 but I don't see Operations anywhere in that diff? It feels nitpicky that we are discussing linter errors Operations API as part of this PR as it is really orthogonal to the changes proposed. Edit... I suck at reading swagger

@TimLovellSmith
Copy link
Copy Markdown
Member Author

@veronicagg I've added the Operations API... its definition slightly varies from CDN's.

Copy link
Copy Markdown
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.

Minor comment regarding descriptions. I agree this change is orthogonal with the proposed change, so in my previous comments I was mostly asking if you were planning on addressing it now or not. What's blocking this PR at the moment, is that we're having issues with CI, I've restarted the job a couple of times, there seems to still be failures, which I'm trying to understand.

Comment thread arm-redis/2016-04-01/swagger/redis.json Outdated
}
},
"OperationListResult": {
"description": "Result of the request to list CDN operations. It contains a list of operations and a URL link to get the next set of results.",
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

please update description

Comment thread arm-redis/2016-04-01/swagger/redis.json Outdated
"items": {
"$ref": "#/definitions/Operation"
},
"description": "List of CDN operations supported by the CDN resource provider."
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

please update description

@veronicagg
Copy link
Copy Markdown
Contributor

@ravbhatnagar do you have any thoughts on the question above regarding OperationsAPI?: "@veronicagg I had a look at pull/40 but I don't see Operations anywhere in that diff? It feels nitpicky that we are discussing linter errors Operations API as part of this PR as it is really orthogonal to the changes proposed. Edit... I suck at reading swagger" thanks!

@TimLovellSmith
Copy link
Copy Markdown
Member Author

@veronicagg Woohoo, checks passed!

@AutorestCI
Copy link
Copy Markdown

@AutorestCI
Copy link
Copy Markdown

@AutorestCI
Copy link
Copy Markdown

@TimLovellSmith
Copy link
Copy Markdown
Member Author

@veronicagg Thank you!

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.

6 participants