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

Create a new version of consumption, with preview budget merge with usage detail and reservation #2289

Merged
merged 11 commits into from
Jan 24, 2018

Conversation

bgsky
Copy link
Contributor

@bgsky bgsky commented Jan 18, 2018

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

@marstr marstr changed the base branch from current to master January 19, 2018 17:02
@marstr
Copy link
Member

marstr commented Jan 19, 2018

We made some updates in December, and moved back to working out of master. current is just a duplicate of master to allow for an easier transition. You can read more about all of the changes we made here: December 2017 Refactoring

@bgsky
Copy link
Contributor Author

bgsky commented Jan 19, 2018

I saw you switched base branch to master. Other than that, let me know what to do with branch on my side and if you have any comments on this pull request.

@marstr
Copy link
Member

marstr commented Jan 19, 2018

I was just swooping in to make sure the PR was targeting the correct branch. I'll hand this back-off to the assignee, @alvadb.

@sandeepnl
Copy link
Contributor

@alvadb @salameer this PR is been pending for more than a day here. Can someone please review this soon?

Copy link
Member

@jhendrixMSFT jhendrixMSFT left a comment

Choose a reason for hiding this comment

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

The model validation failures need to be fixed, please see the travis log.

@jhendrixMSFT
Copy link
Member

@bgsky has this been reviewed and signed off by ARM?

@AutorestCI
Copy link

Was unable to find SDK Azure/azure-sdk-for-python PR for this closed PR.

@jhendrixMSFT jhendrixMSFT reopened this Jan 23, 2018
@bgsky
Copy link
Contributor Author

bgsky commented Jan 23, 2018

@jhendrixMSFT This is merge of previous preview version with stable version. We don't have a ARM review for this pull request yet. Let me fix the errors first.

@deprecatedAccount1
Copy link

Re-assigning to @jhendrixMSFT

@salameer salameer assigned jhendrixMSFT and unassigned alvadb Jan 23, 2018
@jhendrixMSFT jhendrixMSFT added the WaitForARMFeedback <valid label in PR review process> add this label when ARM review is required label Jan 23, 2018
@jhendrixMSFT
Copy link
Member

Can you please provide a link to the preview version from which this swagger originates? Can you also please provide a reference to the PR for the preview version where ARM team signed off?

@jhendrixMSFT jhendrixMSFT removed the WaitForARMFeedback <valid label in PR review process> add this label when ARM review is required label Jan 23, 2018
@bgsky
Copy link
Contributor Author

bgsky commented Jan 23, 2018

Please refer to the following link for the preview version:

#2144

@sandeepnl
Copy link
Contributor

@jhendrixMSFT @salameer

To be clear on the ARM review, this PR is publishing a new version of the api with no changes than what is already GA’ed in our ‘2017-11-30’ api version. We had got it reviewed with ARM team then and nothing has changed on it since then. Should we still get another approval from ARM for this too?

Essentially we are combining the operations available in our swagger versions ‘2017-11-30’ and ‘2017-12-30-preview’ into this.

Please let us know

@jhendrixMSFT
Copy link
Member

@sandeepnl If the ARM team has signed off on the changes for preview then as long as this content is 100% identical there is no need for another review with ARM. It is good to have all the links to previous PRs with ARM's signoff however in #2144 it would appear that the ARM sign-off happened offline as I see no record of it in the PR.

@@ -853,7 +853,7 @@
"type": "object",
"allOf": [
{
"$ref": "#/definitions/ProxyResource"
"$ref": "#/definitions/Resource"
Copy link
Member

Choose a reason for hiding this comment

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

Was this change intentional?

@jhendrixMSFT
Copy link
Member

I merged the two swaggers by hand and diff'ed them with what's presented here and there are a few discrepancies.

  • Path "/providers/Microsoft.Consumption/operations" is missing in this new version
  • Type ProxyResource was renamed to Resource
  • The definition for Resource has changed, specifically the "eTag" field was replaced with the "tags" field, why is that?

@bgsky
Copy link
Contributor Author

bgsky commented Jan 23, 2018

Thanks for merging and comparing. Will fix errors and send another iteration

@sandeepnl
Copy link
Contributor

@bgsky We should have the operations path in the new swagger as well. Please add them and let us talk internally about why etags was removed.
@jhendrixMSFT Thanks for comparing and letting us know.

@bgsky
Copy link
Contributor Author

bgsky commented Jan 23, 2018

@jhendrixMSFT Please lets know if model validation works.

@@ -4,7 +4,7 @@
"scope": "subscriptions/subid/providers/Microsoft.Billing/billingPeriods/201702",
"$expand": "meterDetails,additionalProperties",
"$filter": "usageEnd le 2017-02-14T00:00:00Z",
"$top": "1"
"$top": 1
Copy link
Contributor

Choose a reason for hiding this comment

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

Dont change this version of the swagger/examples. You need to change it in 2018-01-31 version

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 catch. This change is reverted, and new one on latest version is added

@jhendrixMSFT
Copy link
Member

@dsgouda do you know why this model validation is failing? It says "expected type integer but found type string" however the type in the example is type integer. Is this a bug or am I missing something?

@dsgouda
Copy link
Contributor

dsgouda commented Jan 24, 2018

@jhendrixMSFT are these introduced in the current PR? I can't see anything in consumption.json.
I'd say @amarzavery or @mcardosos might have a better idea about model validator.

@jhendrixMSFT
Copy link
Member

Yep this is current, here's the travis log. The operation ID in question is UsageDetails_List, example UsageDetailsExpand.

@dsgouda
Copy link
Contributor

dsgouda commented Jan 24, 2018

😆 I see what's wrong, OpenAPI specs do not recognize integer as a type, use number instead
Reference here

@bgsky
Copy link
Contributor Author

bgsky commented Jan 24, 2018

Would it require the type change on our side? Lets change it to number on our side

@bgsky
Copy link
Contributor Author

bgsky commented Jan 24, 2018

Travis CI build does not start automatically after the latest iteration. Is there an issue somewhere?

@dsgouda
Copy link
Contributor

dsgouda commented Jan 24, 2018

Taking a look.

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

AutoRest Linter Guidelines | AutoRest Linter Issues | Send feedback

Thanks for your co-operation.

@jhendrixMSFT
Copy link
Member

@dsgouda That link is for OpenAPI 3.0 which AutoRest doesn't support (yet). Here's the link to the 2.0 spec. Integer is a valid type and is used in numerous swaggers. I think the bug is elsewhere, likely the model validator. Who owns that?

@jhendrixMSFT
Copy link
Member

I would also add that changing it to number still fails model validation in the same way but with the number type, "Expected type number but found type string".

@dsgouda
Copy link
Contributor

dsgouda commented Jan 24, 2018

You're right @jhendrixMSFT my bad.
Yes, looks like a model validator bug after all. @mcardosos and @veronicagg own the model validator AFAIK.

@jhendrixMSFT
Copy link
Member

@bgsky can you please revert your latest commit so they type is changed back to number? Sorry for the confusion.
@mcardosos is this a known issue with the model validator?

@bgsky
Copy link
Contributor Author

bgsky commented Jan 24, 2018

@jhendrixMSFT My latest commit is to switch integer to number. It was originally integer, and is number now. Would you want to revert it?

@jhendrixMSFT
Copy link
Member

Yes the type should be integer (number is used for floating point/decimal values).

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

AutoRest Linter Guidelines | AutoRest Linter Issues | Send feedback

Thanks for your co-operation.

@jhendrixMSFT
Copy link
Member

I think the model validation failure is a bug, I've opened Azure/oav#197 to track it.

@jhendrixMSFT jhendrixMSFT merged commit 90eb6bc into Azure:master Jan 24, 2018
@AutorestCI
Copy link

Was unable to find SDK Azure/azure-sdk-for-python PR for this closed PR.

@AutorestCI
Copy link

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

@lmazuel
Copy link
Member

lmazuel commented Jan 25, 2018

@jhendrixMSFT This contains a global "budgetName" that should be a method declaration.
Azure/azure-openapi-validator#84

@jhendrixMSFT
Copy link
Member

@lmazuel All I see is budgetNameParameter which is in the path. Am I missing something?

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.

10 participants