-
Notifications
You must be signed in to change notification settings - Fork 900
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
Fix chargeback for container Images with rate assigning by docker label #12851
Conversation
ab9eb63
to
c8dca7c
Compare
<pr_mergeability_checker />This pull request is not mergeable. Please rebase and repush. |
:docker_labels => parse_identifying_attributes(docker_metadata[:Config][:Labels], | ||
'docker_labels', "openshift"), | ||
:docker_labels => docker_labels, | ||
:tags => map_labels('ContainerImage', labels + docker_labels) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Allow mapping of both kubernetes labels and docker labels to tags
@simon3z
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zeari you can't merge labels
and docker_labels
... what if they have the same key but different values? Which one should win? You should keep them separate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@simon3z Im only merging them when sending them to be mapped into tags. This would allow users to turn docker labels into tags for ContainerImages
. I think its unlikely that someone would set a rule on something that would be common for both docker-labels and kubernetes labels.
@cben What would happen in the above case which they have the same key but different values?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@simon3z Im only merging them when sending them to be mapped into tags.
@zeari it's not about how many times or where. If you do it even once you still have to answer the questions above (what if they have the same key but different values? Which one should win? why?).
Is this used by the Chargeback for Images? (IIRC we were basing it on labels)
Let's remove everything that could cause issues and that it's not vital for the use-cases we identified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ooh, docker labels, shiny :)
[First, are these concatenable? Is docker_labels
array of {:name, :value}
hashes?]
I think the mapping code would map both. With same name and 2 values, you might get 2 tags.
Is that what we want? The Right Thing is probably a new mapping column, letting user define independent mappings for k8s labels vs docker labels (and maybe open it to other kinds of custom attrs). Though I'm not excited about making auto-tagging more complicated :-\
Are you also adding docker labels as new virtual custom-attr columns in reports?
There, would you merge a k8s label & docker label of same name into one "column"?
We probably should be consistent between direct label querying / mapped tag querying.
Are you covering docker labels only on images?
https://docs.docker.com/engine/userguide/labels-custom-metadata/ lists several entities.
P.S. This PR does way too much, but you knew that :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[First, are these concatenable? Is docker_labels array of {:name, :value} hashes?]
I think the mapping code would map both. With same name and 2 values, you might get 2 tags.
We could filter the list...
Is that what we want? The Right Thing is probably a new mapping column, letting user define independent mappings for k8s labels vs docker labels (and maybe open it to other kinds of custom attrs). Though I'm not excited about making auto-tagging more complicated :-\
I feel doing this is a whole lot easier than adding label rate assignment code which is turning out as a lot but I may be wrong. Besides, tags are much more integrated into various miq features so this will solve multiple use case scenarios
Are you covering docker labels only on images?
yes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mitigating note: docker labels recommend com.domain.reversed.label
format — if followed, collisions with k8s labels should be rare.
I think the mapping code would map both.
Correction: UI creates categories with single_value=true, so this either won't work, or will be "inconsistent" in DB. Can fix, but let's understand behavior first.
I feel doing this is a whole lot easier than adding label rate assignment code which is turning out as a lot but I may be wrong. Besides, tags are much more integrated into various miq features so this will solve multiple use case scenarios
Fair enough. 👍 to smaller euwe changes and 👍 to less chargeback-special code.
Do we have a longer-term plan?
- UX: will we show k8s labels / docker labels together as just "labels", or will we separate them?
- Will we want independent k8s labels / docker labels mappings?
I'm concerned that if we allow ambiguous "either one" mappings now, and want to separate later, a later migration won't be able to know which was meant.
In any case, we can't do schema changes in euwe. - Will we eventually have direct MiqExpression (virtual column) support for docker labels? Will they show merged with k8s labels or separate?
- Will chargeback rate assignment eventually support [any kind of] labels?
Is there any hope rate assigment will become MiqExpression based to stop playing catch-up?
[aside: Chargeback is not just technical & feature debt, it's a continuous attractor of new debt :-(. IMHO we must allocate more time to gradually make it more based on the core infrastructure...]
c8dca7c
to
508d8fb
Compare
<pr_mergeability_checker />This pull request is not mergeable. Please rebase and repush. |
a68f505
to
a2aac99
Compare
@gtanzillo @lpichler Adding tests, please review. |
@miq-bot remove_label wip |
dac3f66
to
ac28c4c
Compare
80ed182
to
bfaecdf
Compare
|
|
bfaecdf
to
e83ebad
Compare
Fixed |
@miq-bot add_label euwe/yes |
@enoodle please review this as well (it contains some of your PRs and we want to make sure they're integrated properly) |
55c17e8
to
f42f061
Compare
Checked commits zeari/manageiq@43d581e~...f42f061 with ruby 2.2.5, rubocop 0.37.2, and haml-lint 0.16.1 app/controllers/chargeback_controller.rb
app/helpers/container_image_helper/textual_summary.rb
app/helpers/ui_constants.rb
app/models/chargeback.rb
app/models/chargeback/rates_cache.rb
app/models/container_image.rb
app/models/manageiq/providers/openshift/container_manager/refresh_parser.rb
app/models/metric/chargeback_helper.rb
app/models/mixins/assignment_mixin.rb
app/services/container_dashboard_service.rb
app/views/report/_form_filter_chargeback.html.haml
spec/models/chargeback_container_image_spec.rb
spec/models/manageiq/providers/openshift/container_manager/refresher_spec.rb
|
UI changes look good. |
@gtanzillo @lpichler I cant chery pick this into euwe without conflicts and Im having a hard time mapping out the PR's this depends on. is it ok to have euwe specific commits?( #13030) |
@zeari Yes, that's the way to go what it becomes too difficult to cherry-pick. |
Backported to Euwe via #13030 |
This includes work on persisting openshift container images as well as fixes to
ContainerImageChargeback
reportsFix for image names under filter:
@simon3z @enoodle
@miq-bot add_label providers/containers, chargeback, wip