-
Notifications
You must be signed in to change notification settings - Fork 5.1k
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
[Hub Generated] Review request for Microsoft.CostManagement to add version preview/2020-03-01-preview #10407
Conversation
…2019-04-01-preview to version 2020-03-01-preview
Azure Pipelines successfully started running 1 pipeline(s). |
@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 successfully started running 1 pipeline(s). |
Azure Pipelines successfully started running 1 pipeline(s). |
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this 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": { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
...ent/resource-manager/Microsoft.CostManagement/preview/2020-03-01-preview/costallocation.json
Outdated
Show resolved
Hide resolved
"$ref": "#/definitions/RuleStatus", | ||
"description": "Status of the rule" | ||
}, | ||
"createdDate": { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same as above
Azure Pipelines successfully started running 1 pipeline(s). |
Signing off as per below comments from Sachin |
Azure Pipelines successfully started running 1 pipeline(s). |
@zachraMSFT Could you please fix the CI error: LintDiff and Semantic? |
Azure Pipelines successfully started running 1 pipeline(s). |
Azure Pipelines successfully started running 1 pipeline(s). |
Azure Pipelines successfully started running 1 pipeline(s). |
@njuCZ I fixed the errors when I run validation independently, but looks like checks here are stuck |
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.
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.
Please follow the link to find more details on PR review process.