Save network offering_id in usage_id

[sudo87]

Description

This PR fixes #10697 where usage_id is always 1. With this change, network_offering_id will get added in usage_id.

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• build/CI
• test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

How Has This Been Tested?

How did you try to break this feature and the system with this change?

[DaanHoogland]

clgtm, needs testing of usage results though

[DaanHoogland]

@rajujith can you have a look?

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.

Project coverage is 15.90%. Comparing base (f13cf59) to head (f395c35).
Report is 3 commits behind head on 4.19.

Files with missing lines	Patch %	Lines
...cloud/usage/parser/NetworkOfferingUsageParser.java	0.00%	3 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               4.19   #10721      +/-   ##
============================================
+ Coverage     15.17%   15.90%   +0.72%     
- Complexity    11332    11336       +4     
============================================
  Files          5415     5046     -369     
  Lines        474893   445220   -29673     
  Branches      57920    52711    -5209     
============================================
- Hits          72046    70794    -1252     
+ Misses       394792   366514   -28278     
+ Partials       8055     7912     -143     

Flag	Coverage Δ
uitests	?
unittests	15.90% <0.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[winterhazel]

This change does not make sense for me. Why are we including the network offering's ID in usage_id when the ID is already in offering_id? I think we should leave it as it is.

I know that the naming does not make much sense, but this field represents whether the NIC associated with the helper entry is a VM's default one. With this change, we do not have that information anymore, possibly breaking integrations.

[DaanHoogland]

@winterhazel the usage_id is meant to be the id of the resource being used, isn’t it? Why would this be different for usage_type 13 than it is for other usage_types?

[winterhazel]

@DaanHoogland not having the resource's ID here is undoubtedly inconsistent with other usage types. Regardless, I expect that there has been at least a reason/use case that prompted the introduction of this value (defaultNic) into the usage record, although definitely not in such a good way. Removing this from the record would break that, and possibly other integrations that were developed over this odd organization.

Therefore, considering that the network offering is already available in the usage record, that these are (presumably) working currently, and that the change can break them, I do not think that it would be beneficial to change it for the sake of consistency.

Maybe deprecating this usage type and working on an improved version (e.g. a NIC type) would be a better direction? See #10697 (comment). This usage type's behavior is weird considering its name, and I frequently see people not understanding how it works, performing rating over it, and ending up with unexpected values.

[DaanHoogland]

clear,
let’ s indeed think about deprecating it than.
@sudo87 , do you understand @winterhazel ‘ s argument? (and sorry about your PR ;)

[sudo87]

Yeah Daan, thanks @winterhazel. We can close this pr and probably resolve the linked bug as well.

[weizhouapache]

right now I do not know what the usage_id should be .
I think we'd better change it (maybe to the ID of network offering`). but it will breaks the backward compatibility.

@sudo87
can you check the source code and summarize what the usage_id is for other usage types ?
for example

[weizhouapache]

did some testing (add/remove new nic, change default nic, etc), found some issues.
the usage record looks ok

    {
      "description": "Network offering DefaultNetworkOfferingforKubernetesService (7814ca8d-492c-4ed0-b230-47041ea91615) usage for VM cks-admin-project-node-19619af0cd3 (f21221dc-5911-44d7-b3b9-8b0e45f7cd94) ",
      "domain": "ROOT",
      "domainid": "318b9a5d-2ae8-11ef-9466-1e00c400042b",
      "domainpath": "/",
      "enddate": "2025-04-16T23:59:59+0000",
      "isdefault": true,                                                 <==========this is from usage_id
      "offeringid": "7814ca8d-492c-4ed0-b230-47041ea91615",
      "project": "admin-project",
      "projectid": "65d156d6-ffbb-49b7-a0b2-11e11aa16ab4",
      "rawusage": "13.363333",
      "startdate": "2025-04-16T00:00:00+0000",
      "tags": [],
      "usage": "13.363333 Hrs",
      "usagetype": 13,
      "virtualmachineid": "f21221dc-5911-44d7-b3b9-8b0e45f7cd94",
      "zoneid": "1b653d56-15bf-4bd7-8751-9f4c561e6dd8"
    }

I agree it is better to keep as it is now.
@DaanHoogland @sudo87 @winterhazel