GutoVeronezi commented on PR #8243: URL: https://github.com/apache/cloudstack/pull/8243#issuecomment-2038868041
@winterhazel @DaanHoogland I did some tests with the proposal; following there are some detailed descriptions of the tests (hope you guys can find time to read it 😃) and some adjustments that need to be done. --- For context: - both `usage.aggregation.timezone` and `usage.execution.timezone` are configured as `GMT-5`: ![image](https://github.com/apache/cloudstack/assets/38945620/2cc3ce36-17b4-4683-bf30-7cfab8c70903) - the OS where Management Server and Usage server are running is configured with `GMT-3`: ``` root@mgmt:~# date Thu Apr 4 10:27:30 PM -03 2024 ``` - the database is in UTC. --- ## `listUsageRecords` Following there is the data I worked with. <details><summary>Data</summary> ```sql MariaDB [cloud_usage]> select id, account_id, domain_id, description, usage_type, raw_usage, start_date, end_date from cloud_usage order by usage_type, start_date; +-----+------------+-----------+-------------------------------------------+------------+---------------------+---------------------+---------------------+ | id | account_id | domain_id | description | usage_type | raw_usage | start_date | end_date | +-----+------------+-----------+-------------------------------------------+------------+---------------------+---------------------+---------------------+ | 26 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 0.24111109972000122 | 2024-04-02 03:00:00 | 2024-04-02 03:59:59 | | 27 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 0.2894444465637207 | 2024-04-02 03:00:00 | 2024-04-02 03:59:59 | | 29 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 04:00:00 | 2024-04-02 04:59:59 | | 30 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 04:00:00 | 2024-04-02 04:59:59 | | 32 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 05:00:00 | 2024-04-02 05:59:59 | | 33 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 05:00:00 | 2024-04-02 05:59:59 | | 35 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 06:00:00 | 2024-04-02 06:59:59 | | 36 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 06:00:00 | 2024-04-02 06:59:59 | | 38 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 07:00:00 | 2024-04-02 07:59:59 | | 39 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 07:00:00 | 2024-04-02 07:59:59 | | 41 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 08:00:00 | 2024-04-02 08:59:59 | | 42 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 08:00:00 | 2024-04-02 08:59:59 | | 44 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 09:00:00 | 2024-04-02 09:59:59 | | 45 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 09:00:00 | 2024-04-02 09:59:59 | | 47 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 10:00:00 | 2024-04-02 10:59:59 | | 48 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 10:00:00 | 2024-04-02 10:59:59 | | 50 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 11:00:00 | 2024-04-02 11:59:59 | | 51 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 11:00:00 | 2024-04-02 11:59:59 | | 53 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 12:00:00 | 2024-04-02 12:59:59 | | 54 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 12:00:00 | 2024-04-02 12:59:59 | | 56 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 13:00:00 | 2024-04-02 13:59:59 | | 57 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 13:00:00 | 2024-04-02 13:59:59 | | 59 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 14:00:00 | 2024-04-02 14:59:59 | | 60 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 14:00:00 | 2024-04-02 14:59:59 | | 62 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 15:00:00 | 2024-04-02 15:59:59 | | 63 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 15:00:00 | 2024-04-02 15:59:59 | | 65 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 16:00:00 | 2024-04-02 16:59:59 | | 66 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 16:00:00 | 2024-04-02 16:59:59 | | 68 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 17:00:00 | 2024-04-02 17:59:59 | | 69 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 17:00:00 | 2024-04-02 17:59:59 | | 71 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 18:00:00 | 2024-04-02 18:59:59 | | 72 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 18:00:00 | 2024-04-02 18:59:59 | | 74 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 19:00:00 | 2024-04-02 19:59:59 | | 75 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 19:00:00 | 2024-04-02 19:59:59 | | 77 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 20:00:00 | 2024-04-02 20:59:59 | | 78 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 20:00:00 | 2024-04-02 20:59:59 | | 80 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 21:00:00 | 2024-04-02 21:59:59 | | 81 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 21:00:00 | 2024-04-02 21:59:59 | | 83 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 22:00:00 | 2024-04-02 22:59:59 | | 84 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 22:00:00 | 2024-04-02 22:59:59 | | 86 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 23:00:00 | 2024-04-02 23:59:59 | | 87 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-02 23:00:00 | 2024-04-02 23:59:59 | | 89 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-03 00:00:00 | 2024-04-03 00:59:59 | | 90 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-03 00:00:00 | 2024-04-03 00:59:59 | | 92 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-03 01:00:00 | 2024-04-03 01:59:59 | | 93 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-03 01:00:00 | 2024-04-03 01:59:59 | | 95 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-03 02:00:00 | 2024-04-03 02:59:59 | | 96 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-03 02:00:00 | 2024-04-03 02:59:59 | | 98 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-03 03:00:00 | 2024-04-03 03:59:59 | | 99 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-03 03:00:00 | 2024-04-03 03:59:59 | | 101 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-03 04:00:00 | 2024-04-03 04:59:59 | | 102 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-03 04:00:00 | 2024-04-03 04:59:59 | | 104 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-03 05:00:00 | 2024-04-03 05:59:59 | | 105 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-03 05:00:00 | 2024-04-03 05:59:59 | | 107 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-03 06:00:00 | 2024-04-03 06:59:59 | | 108 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-03 06:00:00 | 2024-04-03 06:59:59 | | 110 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-03 07:00:00 | 2024-04-03 07:59:59 | | 111 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-03 07:00:00 | 2024-04-03 07:59:59 | | 113 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-03 08:00:00 | 2024-04-03 08:59:59 | | 114 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-03 08:00:00 | 2024-04-03 08:59:59 | | 116 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-03 09:00:00 | 2024-04-03 09:59:59 | | 117 | 2 | 1 | Volume Id: 1 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-03 09:00:00 | 2024-04-03 09:59:59 | | 119 | 2 | 1 | Volume Id: 2 usage time (DiskOffering: 3) | 6 | 1 | 2024-04-03 10:00:00 | 2024-04-03 10:59:59 | +-----+------------+-----------+-------------------------------------------+------------+---------------------+---------------------+---------------------+ ``` </details> In this test, I was filtering the data with a start date equal or greater to `2024-04-02T03:00:00+0000` and an end date less or equal to `2024-04-02T05:00:00+0000`; therefore, I was expecting to receive the data regarding the entries with IDs 26, 27, 29 and 30. Before applying the patch, the API returned random data, which can be noticed by the `rawusage` attribute that does not contain the values expected for the entries with IDs 26 and 27. Also, the attributes `startdate` and `enddate` in the response presented the expected date (`2024-04-02`) and time (`03:00:00`), according to the filter I did; however, I requested the data in UTC, and it presented a data considering the timezone configured in the global settings (`GMT-5`), which is pretty confusing. <details><summary><code>listUsageRecord</code> before applying the patch</summary> ``` (localcloud) 🐱 > list usagerecords accountid=2 type=6 startdate=2024-04-02T03:00:00+0000 enddate=2024-04-02T05:00:00+0000 { "count": 4, "usagerecord": [ { "account": "admin", "accountid": "5c6b89e7-f09a-11ee-84ff-5254008551cd", "description": "Volume usage for test-2 (f050638c-24e2-469d-a798-567685fda3b3) with disk offering Small (7b148fcb-f2c4-4d4c-8daf-dee609034bd2) and size (5.00 GB) 5368709120", "domain": "ROOT", "domainid": "49d58d3c-f09a-11ee-84ff-5254008551cd", "enddate": "2024-04-02'T'03:59:59-05:00", "offeringid": "7b148fcb-f2c4-4d4c-8daf-dee609034bd2", "rawusage": "1", "size": 5368709120, "startdate": "2024-04-02'T'03:00:00-05:00", "tags": [], "usage": "1 Hrs", "usageid": "f050638c-24e2-469d-a798-567685fda3b3", "usagetype": 6, "zoneid": "b751e541-3a12-4e86-a4bc-9a06b192359a" }, { "account": "admin", "accountid": "5c6b89e7-f09a-11ee-84ff-5254008551cd", "description": "Volume usage for test-1 (2a8d93b8-3be2-446d-bde8-a3c59b91bba0) with disk offering Small (7b148fcb-f2c4-4d4c-8daf-dee609034bd2) and size (5.00 GB) 5368709120", "domain": "ROOT", "domainid": "49d58d3c-f09a-11ee-84ff-5254008551cd", "enddate": "2024-04-02'T'03:59:59-05:00", "offeringid": "7b148fcb-f2c4-4d4c-8daf-dee609034bd2", "rawusage": "1", "size": 5368709120, "startdate": "2024-04-02'T'03:00:00-05:00", "tags": [], "usage": "1 Hrs", "usageid": "2a8d93b8-3be2-446d-bde8-a3c59b91bba0", "usagetype": 6, "zoneid": "b751e541-3a12-4e86-a4bc-9a06b192359a" }, { "account": "admin", "accountid": "5c6b89e7-f09a-11ee-84ff-5254008551cd", "description": "Volume usage for test-2 (f050638c-24e2-469d-a798-567685fda3b3) with disk offering Small (7b148fcb-f2c4-4d4c-8daf-dee609034bd2) and size (5.00 GB) 5368709120", "domain": "ROOT", "domainid": "49d58d3c-f09a-11ee-84ff-5254008551cd", "enddate": "2024-04-02'T'04:59:59-05:00", "offeringid": "7b148fcb-f2c4-4d4c-8daf-dee609034bd2", "rawusage": "1", "size": 5368709120, "startdate": "2024-04-02'T'04:00:00-05:00", "tags": [], "usage": "1 Hrs", "usageid": "f050638c-24e2-469d-a798-567685fda3b3", "usagetype": 6, "zoneid": "b751e541-3a12-4e86-a4bc-9a06b192359a" }, { "account": "admin", "accountid": "5c6b89e7-f09a-11ee-84ff-5254008551cd", "description": "Volume usage for test-1 (2a8d93b8-3be2-446d-bde8-a3c59b91bba0) with disk offering Small (7b148fcb-f2c4-4d4c-8daf-dee609034bd2) and size (5.00 GB) 5368709120", "domain": "ROOT", "domainid": "49d58d3c-f09a-11ee-84ff-5254008551cd", "enddate": "2024-04-02'T'04:59:59-05:00", "offeringid": "7b148fcb-f2c4-4d4c-8daf-dee609034bd2", "rawusage": "1", "size": 5368709120, "startdate": "2024-04-02'T'04:00:00-05:00", "tags": [], "usage": "1 Hrs", "usageid": "2a8d93b8-3be2-446d-bde8-a3c59b91bba0", "usagetype": 6, "zoneid": "b751e541-3a12-4e86-a4bc-9a06b192359a" } ] } ``` </details> After applying the patch, the API returned the correct data, which can be noticed by the `rawusage` attribute that contain the values expected for the entries with IDs 26 and 27. The attributes `startdate` and `enddate` in the response present the expected date and time; however, in the timezone of the server. The response should present the data in UTC, not in the server timezone (**Adjustment 1**). <details><summary><code>listUsageRecord</code> after applying the patch</summary> ``` (localcloud) 🐱 > list usagerecords accountid=2 type=6 startdate=2024-04-02T03:00:00+0000 enddate=2024-04-02T05:00:00+0000 { "count": 4, "usagerecord": [ { "account": "admin", "accountid": "5c6b89e7-f09a-11ee-84ff-5254008551cd", "description": "Volume usage for test-2 (f050638c-24e2-469d-a798-567685fda3b3) with disk offering Small (7b148fcb-f2c4-4d4c-8daf-dee609034bd2) and size (5.00 GB) 5368709120", "domain": "ROOT", "domainid": "49d58d3c-f09a-11ee-84ff-5254008551cd", "enddate": "2024-04-02T00:59:59-0300", "offeringid": "7b148fcb-f2c4-4d4c-8daf-dee609034bd2", "rawusage": "0.241111", "size": 5368709120, "startdate": "2024-04-02T00:00:00-0300", "tags": [], "usage": "0.241111 Hrs", "usageid": "f050638c-24e2-469d-a798-567685fda3b3", "usagetype": 6, "zoneid": "b751e541-3a12-4e86-a4bc-9a06b192359a" }, { "account": "admin", "accountid": "5c6b89e7-f09a-11ee-84ff-5254008551cd", "description": "Volume usage for test-1 (2a8d93b8-3be2-446d-bde8-a3c59b91bba0) with disk offering Small (7b148fcb-f2c4-4d4c-8daf-dee609034bd2) and size (5.00 GB) 5368709120", "domain": "ROOT", "domainid": "49d58d3c-f09a-11ee-84ff-5254008551cd", "enddate": "2024-04-02T00:59:59-0300", "offeringid": "7b148fcb-f2c4-4d4c-8daf-dee609034bd2", "rawusage": "0.289444", "size": 5368709120, "startdate": "2024-04-02T00:00:00-0300", "tags": [], "usage": "0.289444 Hrs", "usageid": "2a8d93b8-3be2-446d-bde8-a3c59b91bba0", "usagetype": 6, "zoneid": "b751e541-3a12-4e86-a4bc-9a06b192359a" }, { "account": "admin", "accountid": "5c6b89e7-f09a-11ee-84ff-5254008551cd", "description": "Volume usage for test-2 (f050638c-24e2-469d-a798-567685fda3b3) with disk offering Small (7b148fcb-f2c4-4d4c-8daf-dee609034bd2) and size (5.00 GB) 5368709120", "domain": "ROOT", "domainid": "49d58d3c-f09a-11ee-84ff-5254008551cd", "enddate": "2024-04-02T01:59:59-0300", "offeringid": "7b148fcb-f2c4-4d4c-8daf-dee609034bd2", "rawusage": "1", "size": 5368709120, "startdate": "2024-04-02T01:00:00-0300", "tags": [], "usage": "1 Hrs", "usageid": "f050638c-24e2-469d-a798-567685fda3b3", "usagetype": 6, "zoneid": "b751e541-3a12-4e86-a4bc-9a06b192359a" }, { "account": "admin", "accountid": "5c6b89e7-f09a-11ee-84ff-5254008551cd", "description": "Volume usage for test-1 (2a8d93b8-3be2-446d-bde8-a3c59b91bba0) with disk offering Small (7b148fcb-f2c4-4d4c-8daf-dee609034bd2) and size (5.00 GB) 5368709120", "domain": "ROOT", "domainid": "49d58d3c-f09a-11ee-84ff-5254008551cd", "enddate": "2024-04-02T01:59:59-0300", "offeringid": "7b148fcb-f2c4-4d4c-8daf-dee609034bd2", "rawusage": "1", "size": 5368709120, "startdate": "2024-04-02T01:00:00-0300", "tags": [], "usage": "1 Hrs", "usageid": "2a8d93b8-3be2-446d-bde8-a3c59b91bba0", "usagetype": 6, "zoneid": "b751e541-3a12-4e86-a4bc-9a06b192359a" } ] } ``` </details> --- ## `quotaStatement` and `quotaBalance` @winterhazel, you mentioned in the description that this PR also affects `quotaStatement` and `quotaBalance`; however, I am not seeing changes in their command classes. Could you check? Also, I checked the code and observed that both have an odd behavior: they take the end date passed as parameters and calculate the next day to it, to use it as the end date, instead of using what the caller passed, which means it would not retrieve what the caller requested. It would be good to check this behavior as well (**Adjustment 2**). ``` public Date getEndDate() { return _responseBuilder.startOfNextDay(endDate == null ? new Date() : new Date(endDate.getTime())); } ``` --- ## `quotaCredits` Before applying the patch, I added credits to an account and ACS added the credits in the future. The response returned the correct value; however, it was in the future in the database: - API call ``` (localcloud) 🐱 > quota credits account=admin value=50 domainid=49d58d3c-f09a-11ee-84ff-5254008551cd { "quotacredits": { "credits": 50, "currency": "$", "updated_by": "admin", "updated_on": "2024-04-05T01:27:08+0000" } } ``` - database ```sql MariaDB [cloud_usage]> select now(); +---------------------+ | now() | +---------------------+ | 2024-04-05 01:31:43 | +---------------------+ 1 row in set (0.000 sec) MariaDB [cloud_usage]> select * from quota_credits; +----+------------+-----------+---------+---------------------+------------+ | id | account_id | domain_id | credit | updated_on | updated_by | +----+------------+-----------+---------+---------------------+------------+ | 1 | 2 | 1 | 50.0000 | 2024-04-05 06:27:08 | 2 | +----+------------+-----------+---------+---------------------+------------+ 1 row in set (0.000 sec) ``` After applying the patch, I added credits to an account and ACS added the credits correctly. However, the response presented the data in the timezone of the server. The response should present the data in UTC, not in the server timezone (**Adjustment 3**). - API call ``` (localcloud) 🐱 > quota credits account=admin value=50 domainid=49d58d3c-f09a-11ee-84ff-5254008551cd { "quotacredits": { "credits": 50, "currency": "$", "updated_by": "admin", "updated_on": "2024-04-04T23:07:44-0300" } } ``` - database ``` MariaDB [cloud_usage]> select * from quota_credits; +----+------------+-----------+---------+---------------------+------------+ | id | account_id | domain_id | credit | updated_on | updated_by | +----+------------+-----------+---------+---------------------+------------+ | 1 | 2 | 1 | 50.0000 | 2024-04-05 06:27:08 | 2 | | 2 | 2 | 1 | 50.0000 | 2024-04-05 02:07:44 | 2 | +----+------------+-----------+---------+---------------------+------------+ 2 rows in set (0.000 sec) MariaDB [cloud_usage]> select now(); +---------------------+ | now() | +---------------------+ | 2024-04-05 02:08:07 | +---------------------+ 1 row in set (0.000 sec) ``` --- ## `quotaTariffCreate` Before applying the patch, I created a tariff passing some values in UTC to `startdate` and `enddate`. The response returned different data than the values passed as parameters and the database was also wrong: - API call ``` (localcloud) 🐱 > quota tariffcreate name=before startdate=2024-04-05T03:00:00+0000 enddate=2024-04-05T06:00:00+0000 usagetype=6 value=40 { "quotatariff": { "currency": "$", "effectiveDate": "2024-04-05T08:00:00+0000", "endDate": "2024-04-05T11:00:00+0000", "name": "before", "tariffValue": 40, "usageDiscriminator": "None", "usageName": "VOLUME", "usageType": 6, "usageTypeDescription": "Volume Usage", "usageUnit": "GB*Month", "uuid": "170f5b1b-ba17-415b-86a0-af6ebd58e5a5" } } ``` - database ```sql MariaDB [cloud_usage]> select * from quota_tariff where name = 'before'; +----+------------+------------+------------+---------------------+----------------+---------------------+---------------------+------------+--------------------------------------+--------+-------------+-----------------+---------+---------------------+ | id | usage_type | usage_name | usage_unit | usage_discriminator | currency_value | effective_on | updated_on | updated_by | uuid | name | description | activation_rule | removed | end_date | +----+------------+------------+------------+---------------------+----------------+---------------------+---------------------+------------+--------------------------------------+--------+-------------+-----------------+---------+---------------------+ | 24 | 6 | VOLUME | GB*Month | None | 40.00000 | 2024-04-05 08:00:00 | 2024-04-05 08:00:00 | 1 | 170f5b1b-ba17-415b-86a0-af6ebd58e5a5 | before | NULL | NULL | NULL | 2024-04-05 11:00:00 | +----+------------+------------+------------+---------------------+----------------+---------------------+---------------------+------------+--------------------------------------+--------+-------------+-----------------+---------+---------------------+ ``` After applying the patch, I created a tariff passing some values in UTC to `startdate` and `enddate`. The tariff was created correctly; however, the response presented the data in the timezone of the server. The response should present the data in UTC, not in the server timezone (**Adjustment 4**). - API call ``` (localcloud) 🐱 > quota tariffcreate name=after startdate=2024-04-05T03:00:00+0000 enddate=2024-04-05T06:00:00+0000 usagetype=6 value=40 { "quotatariff": { "currency": "$", "effectiveDate": "2024-04-05T00:00:00-0300", "endDate": "2024-04-05T03:00:00-0300", "id": "46a2fd8d-a6d1-415e-b2f0-e62d6ad816bf", "name": "after", "tariffValue": 40, "usageDiscriminator": "None", "usageName": "VOLUME", "usageType": 6, "usageTypeDescription": "Volume Usage", "usageUnit": "GB*Month" } } ``` - database ``` MariaDB [cloud_usage]> select * from quota_tariff where name = 'after'; +----+------------+------------+------------+---------------------+----------------+---------------------+---------------------+------------+--------------------------------------+-------+-------------+-----------------+---------+---------------------+ | id | usage_type | usage_name | usage_unit | usage_discriminator | currency_value | effective_on | updated_on | updated_by | uuid | name | description | activation_rule | removed | end_date | +----+------------+------------+------------+---------------------+----------------+---------------------+---------------------+------------+--------------------------------------+-------+-------------+-----------------+---------+---------------------+ | 26 | 6 | VOLUME | GB*Month | None | 40.00000 | 2024-04-05 03:00:00 | 2024-04-05 03:00:00 | 1 | 46a2fd8d-a6d1-415e-b2f0-e62d6ad816bf | after | NULL | NULL | NULL | 2024-04-05 06:00:00 | +----+------------+------------+------------+---------------------+----------------+---------------------+---------------------+------------+--------------------------------------+-------+-------------+-----------------+---------+---------------------+ 1 row in set (0.000 sec) ``` --- ## `quotaTariffList` Before applying the patch, I tried to list the tariff I created in the test before. The filtered the tariff by `startdate` according to how it was in the database; however, no data was returned: ``` (localcloud) 🐱 > quota tarifflist startdate='2024-04-05T08:00:00+0000' (localcloud) 🐱 > ``` After applying the patch, I did the same filter and now it returned the correct data. However, the response presented the data in the timezone of the server. The response should present the data in UTC, not in the server timezone (**Adjustment 5**). ``` (localcloud) 🐱 > quota tarifflist startdate='2024-04-05T08:00:00+0000' { "count": 1, "quotatariff": [ { "currency": "$", "effectiveDate": "2024-04-05T05:00:00-0300", "endDate": "2024-04-05T09:00:00-0300", "id": "60b8769f-2daa-4ae5-bce0-acb4c766807a", "name": "before", "tariffValue": 40, "usageDiscriminator": "None", "usageName": "VOLUME", "usageType": 6, "usageTypeDescription": "Volume Usage", "usageUnit": "GB*Month" } ] ``` --- ## `quotaTariffUpdate` Before applying the patch, I updated the `enddate` of my first tariff. The response returned different data than the values passed as parameters and the database was also wrong: - API call ``` (localcloud) 🐱 > quota tariffupdate name=before enddate=2024-04-05T07:00:00+0000 { "quotatariff": { "currency": "$", "effectiveDate": "2024-04-05T08:00:00+0000", "endDate": "2024-04-05T12:00:00+0000", "name": "before", "tariffValue": 40, "usageDiscriminator": "None", "usageName": "VOLUME", "usageType": 6, "usageTypeDescription": "Volume Usage", "usageUnit": "GB*Month", "uuid": "60b8769f-2daa-4ae5-bce0-acb4c766807a" } } ``` - database ``` MariaDB [cloud_usage]> select * from quota_tariff where name = 'before'; +----+------------+------------+------------+---------------------+----------------+---------------------+---------------------+------------+--------------------------------------+--------+-------------+-----------------+---------------------+---------------------+ | id | usage_type | usage_name | usage_unit | usage_discriminator | currency_value | effective_on | updated_on | updated_by | uuid | name | description | activation_rule | removed | end_date | +----+------------+------------+------------+---------------------+----------------+---------------------+---------------------+------------+--------------------------------------+--------+-------------+-----------------+---------------------+---------------------+ | 24 | 6 | VOLUME | GB*Month | None | 40.00000 | 2024-04-05 08:00:00 | 2024-04-05 08:00:00 | 1 | 170f5b1b-ba17-415b-86a0-af6ebd58e5a5 | before | NULL | NULL | 2024-04-05 06:40:57 | 2024-04-05 11:00:00 | | 25 | 6 | VOLUME | GB*Month | None | 40.00000 | 2024-04-05 08:00:00 | 2024-04-05 08:00:00 | 1 | 60b8769f-2daa-4ae5-bce0-acb4c766807a | before | NULL | NULL | NULL | 2024-04-05 12:00:00 | +----+------------+------------+------------+---------------------+----------------+---------------------+---------------------+------------+--------------------------------------+--------+-------------+-----------------+---------------------+---------------------+ ``` After applying the patch, I updated the `enddate` of my second tariff. The tariff was updated correctly; however, the response presented the data in the timezone of the server. The response should present the data in UTC, not in the server timezone (**Adjustment 6**). - API call ``` (localcloud) 🐱 > quota tariffupdate name=after enddate=2024-04-05T07:00:00+0000 { "quotatariff": { "currency": "$", "effectiveDate": "2024-04-05T00:00:00-0300", "endDate": "2024-04-05T04:00:00-0300", "id": "fe0ee347-7f02-4933-a8af-c656ced6c488", "name": "after", "tariffValue": 40, "usageDiscriminator": "None", "usageName": "VOLUME", "usageType": 6, "usageTypeDescription": "Volume Usage", "usageUnit": "GB*Month" } } ``` - database ```sql MariaDB [cloud_usage]> select * from quota_tariff where name = 'after'; +----+------------+------------+------------+---------------------+----------------+---------------------+---------------------+------------+--------------------------------------+-------+-------------+-----------------+---------------------+---------------------+ | id | usage_type | usage_name | usage_unit | usage_discriminator | currency_value | effective_on | updated_on | updated_by | uuid | name | description | activation_rule | removed | end_date | +----+------------+------------+------------+---------------------+----------------+---------------------+---------------------+------------+--------------------------------------+-------+-------------+-----------------+---------------------+---------------------+ | 26 | 6 | VOLUME | GB*Month | None | 40.00000 | 2024-04-05 03:00:00 | 2024-04-05 03:00:00 | 1 | 46a2fd8d-a6d1-415e-b2f0-e62d6ad816bf | after | NULL | NULL | 2024-04-05 02:18:18 | 2024-04-05 06:00:00 | | 27 | 6 | VOLUME | GB*Month | None | 40.00000 | 2024-04-05 03:00:00 | 2024-04-05 03:00:00 | 1 | fe0ee347-7f02-4933-a8af-c656ced6c488 | after | NULL | NULL | NULL | 2024-04-05 07:00:00 | +----+------------+------------+------------+---------------------+----------------+---------------------+---------------------+------------+--------------------------------------+-------+-------------+-----------------+---------------------+---------------------+ ``` --- ## `quotaTariffDelete` @winterhazel, you mentioned the API `quotaTariffDelete` in the PR's description; however, I am not seeing changes in its command class. I also checked the code and have not found a reason for this API being handled in this PR. Was it a typo? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@cloudstack.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org