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

Adding new properties to Consumption Usage Details #3357

Merged
merged 23 commits into from
Jul 12, 2018

Conversation

ampravinr
Copy link
Contributor

@ampravinr ampravinr commented Jul 5, 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

@AutorestCI
Copy link

AutorestCI commented Jul 5, 2018

Automation for azure-sdk-for-python

The initial PR has been merged into your service PR:
Azure/azure-sdk-for-python#2158

@AutorestCI
Copy link

AutorestCI commented Jul 5, 2018

Automation for azure-sdk-for-java

Nothing to generate for azure-sdk-for-java

@AutorestCI
Copy link

AutorestCI commented Jul 5, 2018

Automation for azure-sdk-for-node

The initial PR has been merged into your service PR:
Azure/azure-sdk-for-node#2700

@ampravinr
Copy link
Contributor Author

@sandeepnl @asarkar84 @ms-premp Please review Usage Details changes

@AutorestCI
Copy link

AutorestCI commented Jul 5, 2018

Automation for azure-sdk-for-ruby

The initial PR has been merged into your service PR:
Azure/azure-sdk-for-ruby#1479

@AutorestCI
Copy link

AutorestCI commented Jul 5, 2018

Automation for azure-sdk-for-go

The initial PR has been merged into your service PR:
Azure/azure-sdk-for-go#2226

Copy link
Contributor

@asarkar84 asarkar84 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.

@@ -0,0 +1,45 @@
{
"parameters": {
"api-version": "2018-05-31",
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's update the api version to 2018-06-30 in all examples.

@annatisch annatisch added the WaitForARMFeedback <valid label in PR review process> add this label when ARM review is required label Jul 5, 2018
@ravbhatnagar ravbhatnagar added ARMSignedOff <valid label in PR review process>add this label when ARM approve updates after review and removed WaitForARMFeedback <valid label in PR review process> add this label when ARM review is required labels Jul 9, 2018
@annatisch
Copy link
Member

Thanks @ampravinr!
I think there might be an omission in the readme.md, as looking at the clients generated from this PR - many operations have been removed - is that intentional?
e.g. Python:
https://github.com/Azure/azure-sdk-for-python/pull/2877/files

@ampravinr
Copy link
Contributor Author

@annatisch Thanks for the review. That is not intentional. Found one issue from my side and working on fixing the same.

…e automatic system since we are manually generating the SDK for Python.
@ampravinr
Copy link
Contributor Author

@annatisch I have made the changes (merged all required operations for the new version and removed the python sdk from the list of auto generated SDK generation - since Python SDK is manually generated). Please review and let me know if any issues.

@sandeepnl
Copy link
Contributor

If i remember correctly python auto-gen was added to handle cases where there were minor non-breaking chganges which can be done without any human intervention.
@lmazuel Can you please confirm if removing python SDK auto-gen is okay?

@ampravinr
Copy link
Contributor Author

@annatisch - I have made all the necessary changes. Could you please verify and let me know if any issues.

@annatisch
Copy link
Member

Thanks @ampravinr - the diff is still showing the loss of some operations groups:
https://github.com/Azure/azure-sdk-for-python/pull/2877/files#diff-ab141b6de2e9066430c19456d8754671

Have these been removed or renamed?

@ampravinr
Copy link
Contributor Author

@annatisch - I verified these changes and the latest changes are good to go.

None of these operations are present in our existing "azure-sdk-for-python/azure-mgmt-consumption/azure/mgmt/consumption/models/init.py" file. Also these operations are suppose to belongs to other namespace (cost-management). I believe the last commits - 7d850c0#diff-ebc1cee9670996e7d7037ed33bd69b9a and 30f1846#diff-ebc1cee9670996e7d7037ed33bd69b9a might have caused this.

We are good with the current changes since those which are missing is not supposed to be in there. Let me know if any issues.

@annatisch
Copy link
Member

Thanks for the confirmation @ampravinr.
There seems to be a number of model validation errors in the examples:
https://travis-ci.org/Azure/azure-rest-api-specs/jobs/402794446

Could you take a look?

@ampravinr
Copy link
Contributor Author

On it now. Thanks.

"tags": [
"Balances"
],
"operationId": "GetBalancesByBillingAccount",
Copy link
Member

@lmazuel lmazuel Jul 11, 2018

Choose a reason for hiding this comment

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

You cannot have at the same time:

  • GetBalancesByBillingAccount_ByBillingPeriod
  • GetBalancesByBillingAccount

Since the syntax XXX_YYY means for Autorest "Creates an operation group called XXX with operation YYY", while the syntax XXX means create "XXX operation". So there is conflict, if GetBalancesByBillingAccount means functions or operation group.

Seeing the url, I would instinctively do:

  • Balances_GetByBillingAccount
  • Balances_GetByBillingPeriod

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 got it. I will make the changes. Thanks a lot @lmazuel

@ampravinr
Copy link
Contributor Author

@annatisch , @lmazuel, @sandeepnl - I have made the necessary changes. Could you please review and let me know if any issue. I see errors in #10878.14 and #10878.15 which I think is not because of our changes. Please let me know if its something I need to fix. Thanks.

}
},
"x-ms-pageable": {
"nextLink
Copy link
Member

Choose a reason for hiding this comment

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

You have both at the same time a model called ReservationRecommendations and an operation ID called ReservationRecommendations.
Usually, the operation is the plural form and the model the singular form: Operation ID ReservationRecommendations has operations that returns list of ReservationRecommendation

Is this true that this model "ReservationRecommendations" is actually ONE recommendation. If yes, please rename it "ReservationRecommendation" (and ReservationRecommendationProperties and ReservationRecommendationListResult)

Having the same string for Operation group ID and a model might (depending of the language) create troubles.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, got it. Let me take a look and will change it accordingly. Thanks again.

Copy link
Member

@lmazuel lmazuel left a comment

Choose a reason for hiding this comment

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

One final comment you may address if it makes sense for your service.

@lmazuel
Copy link
Member

lmazuel commented Jul 12, 2018

@ampravinr Just to triple-check, with this new api version I see that "report_config/billing_account_dimensions/subscription_dimensions/resource_group_dimensions" no longer exists in the final SDK. Could you confirm it's on purpose?

@ampravinr
Copy link
Contributor Author

@lmazuel - I verified the same and we are good here. ResourceGroupDimensions_List operation is moved from Consumption to another namespace\swagger. The same is moved to - "\azure-rest-api-specs\specification\cost-management\resource-manager\Microsoft.CostManagement\stable\2018-05-31\costmanagement.json" now.

@ampravinr
Copy link
Contributor Author

@annatisch - I have made the required changes and not seeing any errors from my side. Please review and let me know if any issues or if any concerns.

@annatisch
Copy link
Member

Thanks @ampravinr - a couple of things:

  • Why did you rename CostTags to CostTagsResult? This model is actually passed in as a request body for the operation CostTags_CreateOrUpdate so calling it "result" is doesn't quite fit :)

  • Please remove the final 's' from the ends of these operations:

    • "Marketplaces_ListByEnrollmentAccounts"
    • "Marketplaces_ListForBillingPeriodByEnrollmentAccounts"
  • I would like to clarify the different between the operations:

    • budgets_get
    • budgets_getByResourceGroupName

    Does this mean that the latter operation will retrieve only the budget for the specified resource group? If so the naming is a bit confusing because the meaning is a bit different then budgets_listByResourceGroup. Maybe this could be better clarified by naming like so:

    • budets_get
    • ResourceGroupBudgets_get (and the same for the equivalent operations, like ResourceGroupBudgets_delete)

    Unless I've misunderstood what these APIs do?

Thanks!

Thanks @lmazuel for taking a look :)

@ampravinr
Copy link
Contributor Author

@annatisch - please find below:

  • changed CostTags to CostTagsResult because we have operations with CostTags like CostTags_Get and according to the errors as well as per @lmazuel that is not a good practice to have it like that.
    I will update the operation id to CostTag and will revert the CostTagsResult to CostTags if that is acceptable.

  • For the Budgets, the later is specific to Resource group. We would like to keep the same naming since all our other operations also follow the same naming. For example - UsageDetails_ListByBillingAccount, UsageDetails_ListByDepartment etc. So we would like to keep the same here. Also this is something from the exsting version (03-31) and we don't have changes in name for these operations.

  • Removing the 's' from ends of these operations "Marketplaces_ListByEnrollmentAccounts" and
    "Marketplaces_ListForBillingPeriodByEnrollmentAccounts"

…nged operations - Marketplaces_ListByEnrollmentAccount and Marketplaces_ListForBillingPeriodByEnrollmentAccount.
@ampravinr
Copy link
Contributor Author

Hi @annatisch, I have made the above changes. Please review and let me know your thoughts. (I have reverted CostTagsResult to CostTag and the operations are now CostTags_*. Let me know if any issues)

@annatisch annatisch merged commit db4a3b3 into Azure:master Jul 12, 2018
@ampravinr
Copy link
Contributor Author

Thanks @annatisch , @lmazuel , @sandeepnl for all the comments and help.

@lmazuel
Copy link
Member

lmazuel commented Jul 12, 2018

@ampravinr About Python, you can fork this branch to save you Autorest call:
Azure/azure-sdk-for-python#2158

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ARMSignedOff <valid label in PR review process>add this label when ARM approve updates after review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants