Prioritize rate with tag of VM when selecting from more rates

[lpichler]

There is a case that more rates can be selected
(for example when storage have more tags)
and in this case, values are accumulated together in report.

so this first way how to deterministically select just one rate
of storage and compute.

So when more rates are selected then
rate with matching tag of VM is used.

This is applied only when rates are assigned to any tagged resources and more rates was selected otherwise behavior is same as before.

[lpichler]

@miq-bot remove_label wip

[lpichler]

cc @sergio-ocon

[chargio]

Do we know which user is generating the report?
It seems that the customer was sharing storage between customers, so we should choose only those tags that are shared between the customer and the storage.
If that is not possible, then we should only choose one if there is more than one tag from the same category... and test whether that would give the proper number for all customers (not only the one with the first tag)

[isimluk]

I think we don't need .try(: here.

This comment however is nitpick and can be ignored.

[lpichler]

yes

options = Chargeback::ReportOptions.new_from_h({})

has always key :tag or method tag

thanks

[lpichler]

Do we know which user is generating the report?

Yes.

It seems that the customer was sharing storage between customers, so we should choose only those tags that are shared between the customer and the storage.

Which tags do you mean ?
Do you mean user's tags ? Which are also on the storage? (accurately tags which are assigned to user's group)
We can get those tags and it is nice idea but it can still leads to ambiguous selections of rates.
(let's assume that user's group has tag A a B and we have assigned tag A to rate R1 and tag B to rate R2, so which should be selected ? )
This is the reason why I am considering tag from report definition(there is just one) in chargeback filters (and using this only in the case when we selected more rates) but it can also leads to ambiguous selections of rates so after it I am simply selecting first rate after sorting.

If that is not possible, then we should only choose one if there is more than one tag from the same category... and test whether that would give the proper number for all customers (not only the one with the first tag)

I am not sure if I understand this point. How to select just one ? Which category do you mean ?

thanks

[chargio]

So the customer was tagging the all the elements for visibility, so everything for customer A was tagged as customer A....
And then it happen to share some elements between others (i.e. the base image was shared, and and adiditional hard drive was used for data, in a similar way that Open Stack would do). Every customer VM would have 1 shared HD and 1 specific HD.
The problem is that the shared HD was visible by every single customer, so it was tagged several times (once per customer), and the calculation would find the tags and associate rates to it, and add them. The customer would end up with a HD tariff that was the sum of every single cost for all customers.

When using one single tag, the report was correct, but visibility not.

[isimluk]

Thanks @sergio-ocon for the detailed description of the problem!

[isimluk]

In the long run, we may want to allow users to define rate-selection-mechanism in the reports editor.

Something like:

Select rate by:

• Select all assigned rates
• Select assigned rates visible to user running the report
• Select the lower (less expensive) rate (hard to define, but valid requirement)
• Select the higher (more expensive) rate
• Pick any
• Use priorities

That is a property of report. -- The assigned rates themselves are function of the resource in time. The selection of the rate of all assigned rates, however, is a function of the report.

[lpichler]

and also

• select rate to prioritize only when multiple selection has happened.

[lpichler]

@sergio-ocon thanks

but when we will somehow prioritize rates according to user's tags then we have to solve also case for admin user which has visibility to everything.

@sergio-ocon @gtanzillo

would be one of solutions acceptable for our case ? (selection in report definition)

[chargio]

@isimluk I believe that in the long run we should change the way rates are selected.

Right now they are filtered by tag, but they should be selected based on service (dependent on the user) or resource. Tags could then be used as modifiers (a VM with this tag has a different cost that another with a different tag)

That would also allow costs to be accrued at different levels (service, project, tenant, etc), that better reflect the real costs (i.e in the cloud network costs are associated to projects, not VM)

[isimluk]

@sergio-ocon, here is an idea:

@isimluk I believe that in the long run (...)

In short run, would it be possible to tag given DataStore(s) by different tag?

• One tag to determine ownership.
• Another tag to determine the rate

This solution should work unless

• there are hundreds of DataStores (too much work)
• each tenant is charged differently

[chargio]

I would need to discuss it to understand the implications.

Can we run a bluejeans?

[gtanzillo]

@lpichler @sergio-ocon @isimluk

I'm thinking that for a short term solution, we can try to select the rate that has at least one tag that the target VM or Storage has. I think this would work in the case that @sergio-ocon illustrated above.

Customer A has everything tagged with "Customer A"
Customer B has everything tagged with "Customer B"
The shared storage is tagged with both "Customer A" and "Customer B"
Compute Rate 1 assigned to VMs tagged with "Customer A"
Compute Rate 2 assigned to VMs tagged with "Customer B"
Storage Rate 1 assigned to datastores tagged with "Customer A"
Storage Rate 2 assigned to datastores tagged with "Customer B"

So currently, getting rates for a VM tagged with "customer A" will return:
Compute Rate 1, Storage Rate 1 and Storage Rate 2

If we filter out the storage rates that don't have an "assigned to tag" matching any of the tags on the VM it would eliminate Storage Rate 2.

I think this could work. What do you think? I can setup a meeting to discuss...

[miq-bot]

<pr_mergeability_checker />This pull request is not mergeable. Please rebase and repush.

[lpichler]

Nice description @gtanzillo. I was looking on this suggestion and it can work.
If I understand well we will basically prioritize rate which is assigned to some tag with tag of VM.
This information(VM's tag) will be taken from MetricRollup#tag_names.

Are you OK with it @isimluk @sergio-ocon ? Or do we need meeting for it ?

thanks

[lpichler]

@gtanzillo @isimluk I implemented suggestion in comment #12534 (comment) - to prioritize tag of VM for selecting rate with this tag.
Description updated.

[gtanzillo]

Looks great, thanks! 👍

[miq-bot]

<pr_mergeability_checker />This pull request is not mergeable. Please rebase and repush.

[miq-bot]

Checked commits lpichler/manageiq@e68eba5~...06720cd with ruby 2.2.5, rubocop 0.37.2, and haml-lint 0.16.1
5 files checked, 0 offenses detected
Everything looks good. 🏆

[lpichler]

@gtanzillo rebased as this was merged and I changed name of methods sort of and I added other wrapper method called rates otherwise it is same as we discussed.

[gtanzillo]

👍 Looks good!

[simaishi]

Backported to Euwe via #13556

[simaishi]

Backported to Darga via #13559