Open winterhazel opened 2 months ago
@blueorangutan package
@winterhazel a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.
Attention: Patch coverage is 68.58974%
with 49 lines
in your changes missing coverage. Please review.
Project coverage is 15.59%. Comparing base (
8ca1843
) to head (a38619c
). Report is 37 commits behind head on main.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Packaging result [SF]: βοΈ el8 βοΈ el9 βοΈ debian βοΈ suse15. SL-JID 10810
@blueorangutan test keepEnv
@DaanHoogland a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests
[SF] Trillian test result (tid-11210) Environment: kvm-ol8 (x2), Advanced Networking with Mgmt server ol8 Total time taken: 48891 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr9590-t11210-kvm-ol8.zip Smoke tests completed. 139 look OK, 0 have errors, 0 did not run Only failed and skipped tests results shown below:
Test | Result | Time (s) | Test File |
---|
@winterhazel , I think this is good to go safe one concern; removing response data from an API response is a backwards incompatibility. I can not judge the gravity (and haven't tested this PR and am not a quota user so just take my concern a little seriously ;) but the principle should only be broken after careful consideration. Can you give some stronger arguments than consistency for removing it, please?
Hey @DaanHoogland, my idea of removing the credits listing from quotaBalance
was to make each API have a single responsibility and make credits-related code changes easier in the future (as we would not have to worry about checking and updating quotaBalance
accordingly anymore when introducing these changes). I don't have a stronger argument for it π
Regarding the gravity of removing it: Quota users would be advised to use quotaCreditsList
to list credit additions instead. However, scripts/automation tools/external software that use quotaBalance
to get the credit addition history of accounts and were not updated before upgrading CloudStack would break. The Quota UI currently uses it to show a list containing the balance and credit addition entries at the same time, but this page will be reworked in the future to separate them, using quotaCreditsList
for listing credit additions instead.
As it would definitely have an impact, I understand why we would want to keep this information in the response, so I'm okay with not removing it. The enhancements to quotaBalance
will still be made without this change.
ok, @winterhazel . I know you and your are the most heavy users of quota so I am not going to -1 this by any means, but my advice would be to leave it in and shout about removing it before you do. you might get work mitigating any regressions if you don't.
Description
When credits are added to an account, an entry that represents the operation is created in
cloud_usage.quota_credits
. Some information about these entries is currently returned alongside an account's balance through thequotaBalance
API. However, this is not consistent with the API's purpose (viewing an account's balance), and it is not possible to view the credit addition history for a whole domain with a single API call.In order to make
quotaBalance
more consistent with its purpose, the credit addition history will be removed from its response alongside some enhancements to the API in the future. To list the credit addition history, this PR adds thequotaCreditsList
, which has the following parameters:accountid
: ID of the account for which the credit statement will be generated.domainid
: ID of the domain for which credit statement will be generated. Available only for administrators.isrecursive
: Whether to generate the credit statement for the provided domain and its children. Defaults to false.startdate
: Start date of the statement. If not provided, the first day of the current month will be considered as the start date.enddate
: End date of the statement. If not provided, the current date will be considered as the end date.No parameters are flagged as required, but at least
accountid
ordomainid
must be provided.Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
How Has This Been Tested?
In my environment, there were the following domains and accounts:
ROOT
: admin (root admin)ROOT/d1
: d1 (domain admin), u1 (user)First, in the root admin account, I added 100 credits to the three accounts; in the domain admin account, I added credits to d1 and u1. Then, I tested the behavior of the API for each account.
For the root admin account:
accountid
tested).enddate
tested).startdate
tested).ROOT
's credits and verified that the response had the expected results (domainid
tested).ROOT
's credits recursively and verified that the response had the expected results (isrecursive
tested).For the domain admin account:
ROOT/d1
's credits history and verified that the response had the expected results.For the user account:
ROOT/d1
and verified that my permission was denied.