-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Comments
offering_id is present in the table, will adding (duplicated) it in usage_id help?
|
This is not a bug. The record's The naming is a bit confusing, but the
|
thanks @winterhazel |
@rajujith , what do you want to do with this issue? |
@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 |
@rajujith yes, we have the NIC's ID in usage records for this type; thus, the 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/ 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. |
@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. |
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
cloudstack/server/src/main/java/com/cloud/api/ApiResponseHelper.java Lines 4192 to 4197 in 9d9737a
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 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. |
Fixed by #10852 |
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.
versions
4.19.2
The steps to reproduce the bug
...
What to do about it?
I am expecting the usage_id should be resource_id i.e, the offering id.
The text was updated successfully, but these errors were encountered: