Skip to content
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

Use current tags for filtering resources in chargeback for VMs #17470

Merged

Conversation

lpichler
Copy link
Contributor

@lpichler lpichler commented May 23, 2018

2 issues:

  • selection of rates based on tags
  • filtering resources to charge them by tags

but We are using MetricRollup#tag_names as tag_names from resources in these two situations and if user will add tags later then related MetricRollup records have still old tags.

So thanks to that it could not choose rate and aslo found any MetricRollup records because in query is used non-current MetricRollup#tag_names.

This fix using current tags and also old tags(in MetricRollups) in for these two places.

Links

@miq-bot miq-bot added the wip label May 23, 2018
@@ -22,7 +22,7 @@ def hash_features_affecting_rate

def tag_names
@tag_names ||= @rollups.inject([]) do |memo, rollup|
memo |= rollup.tag_names.split('|') if rollup.tag_names.present?
memo |= rollup.resource.tags.collect(&:name) if rollup.resource.tags.collect(&:name).present?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I understand this... @lpichler is this capturing the current tag names associated with the resource instead of using the tag names at the time the rollup was created?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes exactly, but I updated it yet - to use both tags from metric rollups and also current tags.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this change is needed for selecting a rates according to tags.

else
scope.where(:resource => vms(region))
end
scope.where(:resource => vms(region))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand this change. Why can we remove this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it was bad touch, now I extended it to posibility filter as according to current tags and also according to old tags.

this change is needed for filtering out resource on report - related to filter tab in report

@lpichler lpichler force-pushed the filter_chargeback_according_to_current_tags branch from 2c58b28 to ec5989e Compare May 24, 2018 15:33
@lpichler lpichler changed the title [WIP] Use current tags for filtering resources in chargeback for VMs Use current tags for filtering resources in chargeback for VMs May 24, 2018
@miq-bot miq-bot removed the wip label May 24, 2018
@@ -22,7 +24,11 @@ def hash_features_affecting_rate

def tag_names
@tag_names ||= @rollups.inject([]) do |memo, rollup|
memo |= rollup.tag_names.split('|') if rollup.tag_names.present?
resource = rollup.resource
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to have a nil resource? Is that why were were using the tags on the rollups originally?

Copy link
Contributor Author

@lpichler lpichler May 24, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes we had a BZ before for this case, if they destroy VM.

probably yes, (it is from origin code) I think that reasons could be more, also performance for example.

memo |= rollup.tag_names.split('|') if rollup.tag_names.present?
resource = rollup.resource
tag_names = []
tag_names |= resource.tags.collect(&:name).map { |x| x.gsub(TAG_PREFIX, "") } if resource
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, cool, you handle the nil resource here

@@ -83,7 +83,8 @@ def self.build_results_for_report_ChargebackVm(options)
def self.where_clause(records, options, region)
scope = records.where(:resource_type => "VmOrTemplate")
if options[:tag] && (@report_user.nil? || !@report_user.self_service?)
scope.for_tag_names(options[:tag].split("/")[2..-1])
scope_with_current_tags = scope.where(:resource => Vm.find_tagged_with(:any => @options[:tag], :ns => '*'))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems odd that we hardcode VmOrTemplate on line 84 and Vm on line 86. This class should have knowledge what classes it's handling at a high level, such as a class method. I'm not sure why it's VmOrTemplate above and Vm below. Should it be VmOrTemplate.find_tagged_with ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes it is -- but we are charging only VMs and not VmOrTemplate. So to have VmOrTemplate here is basically useless.

But reason VmOrTemplate on line 84 is that we are not doing metric rollups for only type VM but for VmOrTemplate.

but if you think that we have to keep it more consistent I can change it to VmOrTemplate.find_tagged_with but it is not needed.

Copy link
Member

@jrafanie jrafanie May 24, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lpichler we can address these hardcoded class names in a followup. It feels like we need a method call to replace these class names:

class ChargebackVm < Chargeback
  ...
  def self.chargeable_resource
    Vm
  end
end

Then, all of these hardcoded places can call chargeable_resource or chargeable_resource.to_s or chargeable_resource.tableize depending if they need Vm, "Vm", or "vms"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, we don't have to do this now, it's just something I'm noticing while looking at these change...

[rate_assignment_options_1, rate_assignment_options_2].each do |rate_assignment|
metric_rollup.tag_names = rate_assignment[:tag].first.tag.send(:name_path)
uniq_rates = chargeback_vm.get(consumption)
@vm.tag_with(["/managed/#{metric_rollup.tag_names}"], :ns => '*')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have a test where a rollup is tagged with one set of tags and the resource/vm is tagged with an additional tag and we confirm that the additional tag is used for running the chargeback report?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very good point 👍 because we don't and I found bug during writing this test.

@lpichler lpichler changed the title Use current tags for filtering resources in chargeback for VMs [WIP] Use current tags for filtering resources in chargeback for VMs May 24, 2018
@miq-bot miq-bot added the wip label May 24, 2018
@lpichler lpichler changed the title [WIP] Use current tags for filtering resources in chargeback for VMs Use current tags for filtering resources in chargeback for VMs May 24, 2018
@lpichler
Copy link
Contributor Author

lpichler commented May 24, 2018

@jrafanie I added test which is covering both issues (one about tag-seleting rates and second about filtering resources described by you #17470 (comment) ) and I did some refactoring in other commits

@miq-bot miq-bot removed the wip label May 24, 2018
@lpichler lpichler force-pushed the filter_chargeback_according_to_current_tags branch from 2445da6 to 9130b57 Compare May 24, 2018 19:37
@miq-bot
Copy link
Member

miq-bot commented May 24, 2018

Checked commits lpichler/manageiq@ec5989e~...9130b57 with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
4 files checked, 0 offenses detected
Everything looks fine. 🏆

@jrafanie
Copy link
Member

@lpichler LGTM. Are both BZs the same issue? Can we close one as a duplicate of the other? I'd rather not reference duplicated BZs in the PR when it gets merged.

@jrafanie
Copy link
Member

@lpichler Please add your branch labels? Is this needed on gaprindashvili/fine/euwe?

@lpichler
Copy link
Contributor Author

@miq-bot add_label gaprindashvili/yes

@lpichler
Copy link
Contributor Author

Are both BZs the same issue?
yes,
and I closed one of the BZ and I marked it as a duplicate.

@jrafanie jrafanie merged commit 1a2a40f into ManageIQ:master May 25, 2018
@jrafanie jrafanie added this to the Sprint 87 Ending Jun 4, 2018 milestone May 25, 2018
@jrafanie jrafanie self-assigned this May 25, 2018
@lpichler lpichler deleted the filter_chargeback_according_to_current_tags branch May 28, 2018 13:07
@JPrause
Copy link
Member

JPrause commented May 29, 2018

@miq-bot add_label blocker

simaishi pushed a commit that referenced this pull request May 29, 2018
…o_current_tags

Use current tags for filtering resources in chargeback for VMs
(cherry picked from commit 1a2a40f)

https://bugzilla.redhat.com/show_bug.cgi?id=1583786
@simaishi
Copy link
Contributor

Gaprindashvili backport details:

$ git log -1
commit ebd3779c686660a4aa15c991fe5ba228d7a5c65e
Author: Joe Rafaniello <[email protected]>
Date:   Fri May 25 11:22:58 2018 -0400

    Merge pull request #17470 from lpichler/filter_chargeback_according_to_current_tags
    
    Use current tags for filtering resources in chargeback for VMs
    (cherry picked from commit 1a2a40f1d6b111f9f1e85e7e568263c32cd624b2)
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1583786

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

Successfully merging this pull request may close these issues.

5 participants