Usage for Default Network offerings are created with usage_id 1

[rajujith]

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]

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

offering_id: 10

[winterhazel]

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]

thanks @winterhazel

[DaanHoogland]

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

[rajujith]

@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]

@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]

@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]

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

cloudstack/usage/src/main/java/com/cloud/usage/parser/NetworkOfferingUsageParser.java

Lines 158 to 162 in 9d9737a

	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);

cloudstack/server/src/main/java/com/cloud/api/ApiResponseHelper.java

Lines 4192 to 4197 in 9d9737a

	} 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