-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Network Usage event model adjustments #10755
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
Network Usage event model adjustments #10755
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 4.19 #10755 +/- ##
============================================
- Coverage 15.17% 15.16% -0.01%
- Complexity 11332 11333 +1
============================================
Files 5415 5412 -3
Lines 474893 475043 +150
Branches 57920 57963 +43
============================================
+ Hits 72046 72055 +9
- Misses 394792 394932 +140
- Partials 8055 8056 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
@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. |
Packaging result [SF]: ✖️ el8 ✖️ el9 ✖️ debian ✖️ suse15. SL-JID 13123 |
@blueorangutan package |
@sureshanaparti 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. |
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 13141 |
...hestration/src/main/java/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
Outdated
Show resolved
Hide resolved
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.
clgtm, I think we can think of some follow up as discussed, but this certainly addresses the initial issue.
@rajujith , can you see if this alleviates any of your usage issues? |
@DaanHoogland This solves the problem for time being. But for the long term we may want to record different usage events like you mentioned here #10687 (comment) and create two separate usage types like we already have for running and allocated VM. |
thanks @rajujith , can you test this with your faulty use-case scenario? @winterhazel would you agree with that requirement? |
@rajujith after looking into and understanding how the network Usage event model works (or was supposed to work), I do not think anymore that it is necessary to add separate events for Also, we include the network's state in the usage record during that period. This can be used to distinguish between allocated and implemented usage. When the running and allocated virtual machine usage types were introduced, we did not have the state column. I'm not sure why it was introduced that way (two different usage types instead of including the state in the usage record), so genuine question: is there an advantage of having two separate usage types just to distinguish between allocated and implemented? For me, it seems unnecessary. |
@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. |
@winterhazel I can only imagine a scenario where the operator would want to bill allocated and Implemented networks at a different rate or as separate products. If these usages can be differentiated in the API response that should be enough. However separate usage type makes a clear distinction in my head, may be its not necessary. |
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 13171 |
@blueorangutan test |
@rohityadavcloud a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
[SF] Trillian Build Failed (tid-13148) |
[SF] Trillian Build Failed (tid-13150) |
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.
LGTM.
Based on my tests the duplicate events are no longer created. No more duplicate usage records are being generated as well.
mysql> select * from usage_event where resource_id=204 and type in ('NETWORK.CREATE','NETWORK.DELETE','NETWORK.UPDATE');
+----+----------------+------------+---------------------+---------+-------------+---------------+-------------+-------------+------+---------------+-----------+--------------+
| id | type | account_id | created | zone_id | resource_id | resource_name | offering_id | template_id | size | resource_type | processed | virtual_size |
+----+----------------+------------+---------------------+---------+-------------+---------------+-------------+-------------+------+---------------+-----------+--------------+
| 2 | NETWORK.CREATE | 2 | 2025-04-25 08:03:40 | 1 | 204 | net1 | 10 | NULL | NULL | NULL | 1 | NULL |
| 6 | NETWORK.UPDATE | 2 | 2025-04-25 08:04:57 | 1 | 204 | net1 | 10 | NULL | NULL | Implemented | 1 | NULL |
| 11 | NETWORK.UPDATE | 2 | 2025-04-25 08:08:58 | 1 | 204 | net1 | 10 | NULL | NULL | Allocated | 1 | NULL |
| 12 | NETWORK.UPDATE | 2 | 2025-04-25 08:11:14 | 1 | 204 | net1 | 10 | NULL | NULL | Implemented | 1 | NULL |
| 19 | NETWORK.UPDATE | 2 | 2025-04-25 08:14:31 | 1 | 204 | net1 | 10 | NULL | NULL | Allocated | 1 | NULL |
| 21 | NETWORK.DELETE | 2 | 2025-04-25 08:14:33 | 1 | 204 | net1 | 10 | NULL | NULL | NULL | 1 | NULL |
+----+----------------+------------+---------------------+---------+-------------+---------------+-------------+-------------+------+---------------+-----------+--------------+
6 rows in set (0.00 sec)
mysql> select account_id,usage_id,usage_type,start_date,end_date from cloud_usage.cloud_usage where usage_id=204;
+------------+----------+------------+---------------------+---------------------+
| account_id | usage_id | usage_type | start_date | end_date |
+------------+----------+------------+---------------------+---------------------+
| 2 | 204 | 30 | 2025-04-25 07:30:00 | 2025-04-25 08:29:59 |
+------------+----------+------------+---------------------+---------------------+
1 row in set (0.00 sec)
@blueorangutan test |
@Pearl1594 a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
[SF] Trillian test result (tid-13143)
|
[SF] Trillian test result (tid-13157)
|
Description
This PR fixes the issues with the network-related Usage event model described in #10687:
NETWORK.CREATE
is not published when the network is created. Instead, it is published after the network is implemented, which does not match what Usage expects and can result in duplicateNETWORK.CREATE
sNETWORK.UPDATE
is published to indicate that the network is implemented only when the method that implements the network is called a second time, such as when deploying a second VM on the network, which does not make much senseImplemented
toAllocated
Types of changes
Feature/Enhancement Scale or Bug Severity
Bug Severity
How Has This Been Tested?
How did you try to break this feature and the system with this change?
Isolated network:
NETWORK.CREATE
was publishedNETWORK.UPDATE
(Implemented
) was publishedNETWORK.UPDATE
(Allocated
) was publishedNETWORK.UPDATE
(Implemented
) was publishedNETWORK.UPDATE
(Allocated
) and aNETWORK.DELETE
were publishedError on isolated network deployment:
router.template.kvm
to a template that does not exist so that the network implementation would fail, created a new network, and tried to deploy a VM on it: onlyNETWORK.CREATE
was published because the implementation failedPersistent networks:
NETWORK.CREATE
and aNETWORK.UPDATE
(Implemented
) were publishedNETWORK.UPDATE
(Allocated
) and aNETWORK.DELETE
were publishedShared networks:
NETWORK.CREATE
was published (which is expected, as there was no state change)NETWORK.DELETE
was publishedL2 networks:
NETWORK.CREATE
was publishedNETWORK.UPDATE
(Implemented
) was publishedNETWORK.UPDATE
(Allocated
) and aNETWORK.DELETE
were publishedKubernetes:
NETWORK.CREATE
and aNETWORK.UPDATE
(Implemented
) were published