-
Notifications
You must be signed in to change notification settings - Fork 897
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
Collect node custom attributes from hawkular during refresh #12924
Conversation
@yaacov PTAL |
@moolitayer @zeari @cben can you review? |
@zgalor I would expected this to be part of What client you use to gather information shouldn't affect where you do the collection. |
@simon3z There is some sense in doing this collection under the new provider. That way we would not interfere with upstream customers out of the box. |
@moolitayer there are few things that we want to do in the hawkular provider but this one seems to really belong to inventory refresh on kubernetes/openshift. @miq-bot assign zgalor |
@miq-bot add_label wip |
<pr_mergeability_checker />This pull request is not mergeable. Please rebase and repush. |
57226ed
to
1e50fd9
Compare
72968d2
to
9d2f188
Compare
@@ -21,6 +21,18 @@ def fetch_entities(client, entities) | |||
end | |||
end | |||
end | |||
|
|||
def fetch_ems_metrics(ems) | |||
hawk = ManageIQ::Providers::Kubernetes::ContainerManager::MetricsCapture::HawkularClient.new(ems) |
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.
@yaacov here I am creating a new HawkularClient for the ems, even though the ems already has a hawkular client for metrics. This is done once in every refresh for each provider.
Is that a good practice? Do you see a better way to do it?
I removed the previous commit - collecting string metrics as part of metric collection and re-implemented as part of refresh. |
@@ -395,6 +395,19 @@ def save_container_volumes_inventory(container_group, hashes, target = nil) | |||
store_ids_for_new_records(container_group.container_volumes, hashes, :name) | |||
end | |||
|
|||
def save_custom_attributes_inventory(entity, hashes, target = nil) |
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.
maybe we can change save_custom_attribute_attribute_inventory
to use this function
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.
I suggest you refactor this in a different PR
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.
Yes. I will rephrase: What a cool function! Lets rewrite save_custom_attribute_attribute_inventory
with it in another PR!
keys = hawk.strings.query(:miq_metric => true) | ||
|
||
metrics = {} | ||
keys.each do |k| |
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.
maybe you can use each_with_objecct
here? instead of defining the metrcis hash and then returning it:
keys.each_with_object({|) do |k, metrics|
.....
end
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.
👍
@@ -20,6 +20,7 @@ def parse_legacy_inventory(ems) | |||
fetch_entities(openshift_client, OPENSHIFT_ENTITIES) | |||
end | |||
entities = openshift_entities.merge(kube_entities) | |||
entities[:metrics] = fetch_ems_metrics(ems) |
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.
Is this only collecting metrics for nodes or also for other entities?
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.
currently we are only sending node metrics, but it will fetch every metric tagged with "miq_metric=true" on this tenant
3bce917
to
f35c0d3
Compare
@zgalor you need a naming suggestion for the section of the nodes custom attributes? |
e73b103
to
0533c24
Compare
9bc4f9c
to
ff1deed
Compare
@zgalor I am not sure |
@simon3z I wanted the inventory parsing to be transparent instead of specific to node so it can be used for other entities. Does "dynamic_attributes" sound better? |
LGTM 👍 cc @chessbyte @miq-bot assign blomquisg |
This pull request is not mergeable. Please rebase and repush. |
ff1deed
to
5767c20
Compare
7959e41
to
b8e41ea
Compare
@@ -395,6 +396,19 @@ def save_container_volumes_inventory(container_group, hashes, target = nil) | |||
store_ids_for_new_records(container_group.container_volumes, hashes, :name) | |||
end | |||
|
|||
def save_additional_attributes_inventory(entity, hashes, target = nil) |
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.
I'd like to see this merge with the save_custom_attributes_inventory method since additional_attributes
is really just an alias for custom_attributes
. But, this has two major differences:
additional_attributes
vs.custom_attributes
in the call tosave_inventory_multi
- this version calls
store_ids_for_new_records
whereassave_custom_attributes_inventory
does not ... and I'm not sure why.
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.
I agree...the model should just be has_many :custom_attributes
instead of trying to create some special naming. If store_ids_for_new_records is needed, there's no reason it can't be added to the existing save_custom_attributes_inventory
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.
On that note though...is custom_attributes the right place for this or should this be in advanced_settings? It depends on the what is going to be store here in the refresh.
The difference is that custom_attributes are things that people manipulate and change, particularly through manageiq. advanced_settings are extended metadata that is mostly for informational purposes.
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.
@Fryguy this is data that we collect daily from the openshift cluster such as rpm version of openshift in each node, and then create a policy that verifies the attributed against the expected version. Could also be certificate fingerprint. Not intended to be manipulated through manageIQ, but to be pushed and changed externally.
@blomquisg I initially created these as regular custom attributes, but as @zeari noted custom_attributes are very generic, and we might want to separate those specific attributes (like we do for labels\selectors\annotations)
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.
@Fryguy will advanced_settings show on the Node/Provider page? Will I be able to use them in conditions?
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.
Hrm, looking at the two tables, I think @Fryguy is backwards on this. advanced_settings
has default_value
, min
, max
, and read_only
attributes. Which to me looks like something that might be used to build a UI for manipulating in ManageIQ.
Whereas custom_attributes
has just section
, name
, value
, and description
. Which, to me means it's data we simply collect and display.
So, it looks like custom_attributes
is where this should stay.
However, I still think it would be better to reuse the custom_attributes
directly (so you could reuse the existing save_custom_attributes_inventory
method, maybe with a the small change of adding store_ids_for_new_records
to the current implementation). Then, you could always group these Hawkular based settings with the section
attribute of custom_attributes
. And, if needed, you could have a special method called additional_attributes
that grabs these Hawkular settings.
That seems better than trying to circumvent the current inventory just to have a collection attribute new name on container_node
.
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.
I changed the code to reuse existing save_custom_attribute_attribute_inventory
.
I kept the additional_attributes
alias same way we do for labels
, for easier access and management and to differentiate those custom_attributes from others.
@blomquisg PTAL
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.
advanced_settings has default_value, min, max, and read_only attributes.
that's because it was built from vmware which gave us those values. advanced_settings there were modifiable, but not common to modify and definitely not modified by us. custom_attributes was closer to like amazon tags or openshift labels, where it was quite common to change/add/delete them. So if this is what these hawkular settings are, then it belongs in custom_attributes.
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.
👍 I like this new change.
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.
Use Hawkular client to fetch metrics with miq_metric tag and save each metric as additional attribute in the relevant node Use store_path and fetch_path to parse additional attributes Add hawk collected custom attribute test in refresher_spec.rb Change metrics_capture/capture_context_spec.rb and related vcr cassetes to work with new refresh.
b8e41ea
to
b5f2f37
Compare
Checked commits zgalor/manageiq@dbc58da~...b5f2f37 with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0 |
This is good @zgalor ... thanks for working with us on it! |
Reading metrics from hawkular tagged with 'miq_metric=true' and saving them as custom attributes in the node they were collected from. This is done in ems refresh process for kubernetes and openshift.
cc @simon3z
@miq-bot add_label providers/containers