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`:
- 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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
