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

[Hub Generated] Review request for Microsoft.CostManagement to add version preview/2020-03-01-preview #10407

Conversation

zachraMSFT
Copy link
Contributor

@zachraMSFT zachraMSFT commented Aug 11, 2020

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.

Contribution checklist:

If any further question about AME onboarding or validation tools, please view the FAQ.

ARM API Review Checklist

  • Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

    • Adding new API(s)
    • Adding a new API version
    • Adding a new service
  • If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist

If there are following updates in the PR, ensure to request an approval from API Review Board as defined in the Breaking Change Policy.

  • Removing API(s) in stable version
  • Removing properties in stable version
  • Removing API version(s) in stable version
  • Updating API in stable version with Breaking Change Validation errors
  • Updating API(s) in preview over 1 year

Please follow the link to find more details on PR review process.

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@zachraMSFT
Copy link
Contributor Author

@chiragg4u Is this the proper configuration to avoid any deprecations and just add a new type with a new version from api perspective? Including the costmanagement.json in preview folder generated avocado errors so it seemed like this was the correct option, but want to make sure.

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Copy link
Contributor

@ravbhatnagar ravbhatnagar left a comment

Choose a reason for hiding this comment

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

@zachraMSFT few comments

}
}
},
"/providers/Microsoft.Billing/billingAccounts/{billingAccountId}/providers/Microsoft.CostManagement/costAllocationRules/checkNameAvailability": {
Copy link
Contributor

Choose a reason for hiding this comment

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

Move the action checkNameAvailability directly under the provider, and then the resource type can be taken in the request body, this will let you use the same method for other resource types where you want to provide this functionality of check name. And it would be compliant with ARM Resource provuder contract -
https://github.com/Azure/azure-resource-manager-rpc/blob/master/v1.0/proxy-api-reference.md#check-name-availability-requests

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is this change required? We already reviewed having the field this way previously (https://github.com/Azure/azure-rest-api-specs-pr/pull/1152) and now have a number of dependencies based on this. Is this a recent change? I thought we configured per recommendations when we implemented it and did not specify resource type.

"$ref": "#/definitions/RuleStatus",
"description": "Status of the rule"
},
"createdDate": {
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 new top level property called systemData. and such fields are part of the schema there. This is dont for consistency sake so that any azure resource will have this data and in the same property. https://github.com/Azure/azure-rest-api-specs/blob/master/specification/common-types/resource-management/v2/types.json#L355
Other details here - https://armwiki.azurewebsites.net/api_contracts/ResourceSystemData.html?q=systemdata

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is this change required? We already reviewed having the field this way previously (https://github.com/Azure/azure-rest-api-specs-pr/pull/1152) and now have a number of dependencies based on this. Since we determined our setup for this before the change, it introduces lots of randomization on us to switch post development

"format": "date-time",
"description": "Time at which the rule was created. Rules that change cost for the same resource are applied in order of creation."
},
"updatedDate": {
Copy link
Contributor

Choose a reason for hiding this comment

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

same as above

@ravbhatnagar ravbhatnagar added the ARMChangesRequested <valid label in PR review process>add this label when require changes after ARM review label Aug 18, 2020
@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@ravbhatnagar
Copy link
Contributor

Signing off as per below comments from Sachin
[9:55 AM] Sachin Srivastava
Is it possible to treat the comments in a separate PR at a later time. We had an earlier review and was approved at that time. Hence we made the API and UX with the existing contract.. and any change at this time would have a lot of ripple effect.
​[9:56 AM] Sachin Srivastava
We are in public-preview state.. and have to set up another iteration before we go GA.

@ravbhatnagar ravbhatnagar added ARMSignedOff <valid label in PR review process>add this label when ARM approve updates after review and removed ARMChangesRequested <valid label in PR review process>add this label when require changes after ARM review WaitForARMFeedback <valid label in PR review process> add this label when ARM review is required labels Aug 19, 2020
@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@njuCZ
Copy link
Contributor

njuCZ commented Aug 20, 2020

@zachraMSFT Could you please fix the CI error: LintDiff and Semantic?

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@zachraMSFT
Copy link
Contributor Author

@njuCZ I fixed the errors when I run validation independently, but looks like checks here are stuck

@njuCZ njuCZ merged commit 7ac0082 into Azure:master Aug 21, 2020
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 CI-BreakingChange-Python
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants