Skip to content

Usage for Default Network offerings are created with usage_id 1 #10697

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

Closed
rajujith opened this issue Apr 11, 2025 · 10 comments
Closed

Usage for Default Network offerings are created with usage_id 1 #10697

rajujith opened this issue Apr 11, 2025 · 10 comments

Comments

@rajujith
Copy link

problem

The usage_id in the cloud_usage table for the resource network offering for the default network offerings is always 1 and seems hardcoded.

mysql> select distinct usage_id from cloud_usage where usage_type=13;
+----------+
| usage_id |
+----------+
|        1 |
+----------+

mysql> select * from cloud_usage.cloud_usage where usage_type=13 and usage_id=1 order by id desc limit 2\G
*************************** 1. row ***************************
              id: 11500
         zone_id: 1
      account_id: 2
       domain_id: 1
     description: Network offering:10 for Vm : 132 usage time
   usage_display: 0.038889 Hrs
      usage_type: 13
       raw_usage: 0.038889169692993164
  vm_instance_id: 132
         vm_name: NULL
     offering_id: 10
     template_id: NULL
        usage_id: 1
            type: NULL
            size: NULL
      network_id: NULL
      start_date: 2025-04-10 05:30:00
        end_date: 2025-04-10 06:29:59
    virtual_size: NULL
       cpu_speed: NULL
       cpu_cores: NULL
          memory: NULL
quota_calculated: 0
       is_hidden: 0
           state: NULL

versions

4.19.2

The steps to reproduce the bug

  1. Deploy instances
  2. Check usage records

...

What to do about it?

I am expecting the usage_id should be resource_id i.e, the offering id.

@sudo87
Copy link
Collaborator

sudo87 commented Apr 15, 2025

offering_id is present in the table, will adding (duplicated) it in usage_id help?

offering_id: 10

@winterhazel
Copy link
Member

winterhazel commented Apr 15, 2025

This is not a bug. The record's usage_id represents whether the NIC that prompted the helper entry's creation is a VM's default NIC.

The naming is a bit confusing, but the NETWORK_OFFERING usage type is related to NICs of a VM associated with a network offering. For instance, suppose we have:

  • a single network with 7 VMs: in this situation, Usage will generate 7 NETWORK_OFFERING usage records, one for each NIC.
  • a single VM with 2 NICs associated to 2 networks using the same network offering: a single usage record with double the usage (grouped because it's the same network offering for the same VM).
  • a single VM with 2 NICs associated to 2 networks using different network offerings: two usage records, one for each NIC.

@rajujith
Copy link
Author

thanks @winterhazel

@DaanHoogland
Copy link
Contributor

@rajujith , what do you want to do with this issue?

@rajujith
Copy link
Author

@DaanHoogland based on the discussions on the #10721 I understand that fixing the inconsistency could break the existing integrations. If its about external integrations that consumes the usage API, we could still change the database to make consistent and make code changes to retain the current response ? while also considering upgrade scenarios. cc @sudo87 @winterhazel

@winterhazel
Copy link
Member

winterhazel commented Apr 25, 2025

@rajujith yes, we have the NIC's ID in usage records for this type; thus, the listUsageRecords API can be adapted to obtain isDefault from the NIC instead to retain the "same" response.

However, there's probably external integrations that query the database directly. Changing what this column represents could break the integrations that expect it to contain a 0/1 indicating whether a NIC is the default one.

Honestly, though, I do not know any specific external integration that consumes the usage records directly from the database instead of consuming from the API, as I work mostly with Quota, but I would not consider it as a scenario that does not exist, because this approach has been suggested some times before:

https://www.shapeblue.com/cloudstack-usage-service-deep-dive/
https://www.slideshare.net/slideshow/dag-sonstebo-cloudstack-usage-service/115784267
http://events17.linuxfoundation.org/sites/events/files/slides/CCCNA14%20presentation.pdf

As I said, I can not pinpoint an external solution that would break due to this, so maybe I'm being unnecessarily concerned, but I think it would be good to consider the impact this change could have before introducing it. I personally think that it's just not necessary or beneficial.

@DaanHoogland
Copy link
Contributor

@winterhazel , I think we shouldn’t humor direct access to the DB too much. If we can think of a workaround for people doing integration that way, fine. But the integrations should always use the API in principle. Worst case we can add a helper field to accomodate such (ab)use.

@sureshanaparti
Copy link
Contributor

sureshanaparti commented Apr 30, 2025

the usage id for the network offering (usage type 13) is to is to indicate default Nic (1) or not (0).

long defaultNic = (isDefault) ? 1 : 0;
UsageVO usageRecord =
new UsageVO(zoneId, account.getId(), account.getDomainId(), usageDesc, usageDisplay + " Hrs", type, new Double(usage), vmId, null, noId, null, defaultNic,
null, startDate, endDate);
s_usageDao.persist(usageRecord);

} else if (usageRecord.getUsageType() == UsageTypes.NETWORK_OFFERING) {
//Network Offering Id
NetworkOfferingVO netOff = _entityMgr.findByIdIncludingRemoved(NetworkOfferingVO.class, usageRecord.getOfferingId().toString());
usageRecResponse.setOfferingId(netOff.getUuid());
//is Default
usageRecResponse.setDefault(usageRecord.getUsageId() == 1);

It is no where referenced as resource_id / offering id. Maybe, this requires some doc update as it returns as Default in the usage response ? what do you think, any thoughts @rajujith @winterhazel cc @DaanHoogland

@sureshanaparti sureshanaparti self-assigned this Apr 30, 2025
@winterhazel
Copy link
Member

@sureshanaparti updating the documentation to match the actual response would definitely be good.

By the way, the Usage documentation seems to not have been update in quite some time. I noticed that it is missing a lot of usage types. Would be good to update it to include these too.

@rajujith
Copy link
Author

Fixed by #10852

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

5 participants