-
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
Add monitoring manager #15354
Add monitoring manager #15354
Conversation
1d8b26d
to
d6f6a81
Compare
d6f6a81
to
c9ed7a3
Compare
@simon3z @blomquisg @Ladas please take a look |
class MonitoringManager < BaseManager | ||
class << model_name | ||
def route_key | ||
"ems_monitoring" |
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.
Actually a routing isn't needed here as this provider should not have separate screens
|
||
def singular_route_key | ||
"ems_monitoring" | ||
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.
you will need def self.ems_type
to pass the specs
hm, strange you have it in the next PR. It should be really only in the leaf class, which might be the problem here, since this is a leaf class, until you define the leaf class.
To pass the specs you will need to ignore this manager in the spec, then merge the leaf class, then re-enable it in the spec :-)
@miq-bot assign @blomquisg looks good in overall, just need the specs fixed |
Thanks @Ladas I'll probably have a few more changes to this PR once I finish the event collection that uses the new managers. |
This pull request is not mergeable. Please rebase and repush. |
c9ed7a3
to
14fc6b1
Compare
03fd6d6
to
e600b4d
Compare
e600b4d
to
76d1251
Compare
extend ActiveSupport::Concern | ||
|
||
included do | ||
# TODO: why is this relation needed ? why is the inheritors relation no enough? |
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 believe AR class methods like has_one
don't create something inheritable (like defining a method).
That's why mixins do this under included
to execute in each class instead of in the mixin.
It obviously does work with class->class STI inheritance — dunno how exactly — but not mixins I think.
I may be wrong.
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 don't want anything inherited in any case. I was wondering why other secondary managers (NetworkManager I think) had this in the parent class. Why shouldn't I remove this relation and just have the relation in the base child class? (e.g ManageIQ::Providers::Openshift::ContainerManager
)
cc @durandom
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.
removing for now
config/permissions.tmpl.yml
Outdated
@@ -35,6 +35,7 @@ | |||
- ems-type:gce_network | |||
- ems-type:hawkular | |||
- ems-type:hawkular_datawarehouse | |||
- ems-type:monitoring |
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.
@moolitayer looking at the other types they're technology-specific (ansible, azure, cinder, ec2, s3, foreman, gce, etc.).
I don't see anything generic (e.g. network, storage, cloud, infra).
Then why "monitoring" instead of probably "prometheus"?
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.
Question is if we will ever want to move existing hawkular stuff under the new manager, like metrics, or introduce a new type of alerting provider implementation
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.
@moolitayer if we do (and we're not planning to) why wouldn't it be a different manager with an hawkular name?
It would be an OpenShift provider with an Hawkular alert manager instead of a Prometheus manager.
Using a generic name here seems out of place.
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.
OK Thanks, turns out this was a mistake, and should only be done for the leaf classes:
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 turns out I do need it until monitoring manager has children[1]
I will remove it in #15506
[1]
manageiq/app/models/ext_management_system.rb
Lines 10 to 12 in f2d7380
def self.leaf_subclasses | |
descendants.select { |d| d.subclasses.empty? } | |
end |
776aed7
to
eb5e1c3
Compare
There is a test failure[1] that does not seem related, restarting... [1] ./spec/models/miq_report_spec.rb:151 |
@simon3z please take a look |
LGTM 👍 cc @blomquisg |
I'm seeing spec/models/miq_report_spec.rb:151 failing on master locally. |
lib/vmdb/loggers.rb
Outdated
@@ -26,6 +26,7 @@ def self.apply_config(config) | |||
apply_config_value(config, $kube_log, :level_kube) | |||
apply_config_value(config, $mw_log, :level_mw) | |||
apply_config_value(config, $datawarehouse_log, :level_datawarehouse) | |||
apply_config_value(config, $monitoring_log, :level_monitoring) |
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.
This seems a little too broad for a logging category (same comment for the logger definition below).
If we're introducing the concept of a Monitor, I could easily see monitoring as a concept spanning multiple providers (OpenStack Gnocci/Ceilometer or AWS CloudWatch for instance). If we refactor some of the other providers to have "monitoring" instead of just "metrics", then I wouldn't want to have a single logger category for that.
In the same way I wouldn't want to have a single "inventory.log" file.
Maybe a better idea here would be "container_monitoring"? I can see why getting more specific with "prometheus_monitoring" or "hawkular_monitoring" is less desirable, since the possibility of reusing those specific services in different providers.
/cc @Fryguy @jrafanie @gtanzillo
Thoughts?
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 a better idea here would be "container_monitoring"?
👍
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 went with container_monitoring for the log and cn_monitoring_log for the logger, so it won't be super long.
767a270
to
e7eac86
Compare
@@ -0,0 +1,21 @@ | |||
module HasMonitoringManagerMixin |
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.
prepare for troubles with this approach.
- validations and creation time Add managers in before_create callback instead of before_validation manageiq-providers-azure#13
- accessing associations through the parent manager [WIP] add hosts and vms as an association #12884
Also what happens if you include HasMonitoringManagerMixin
and HasNetworkingManagerMixin
?
It wont chain ensure_managers
. I was experimenting with HasParentManager
, which would be included into the parent manager, but it also adds some confusion...
So, in the end, I think this linking of managers via parent_manager is flawed, or at least how we set it up.
Unfortunately there is no better way to do this for now 😢
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.
Thanks for the heads up @durandom. I experience some weird stuff (that was solved passing parent_manager to build). We should be good with the first issue and the second one (we use on_create, and Monitoring manager always has a parent_manager).
I should probably change ensure_manager to ensure_X_manager.
I would appreciate it if you can take a look on the manageiq-providers-kubernetes PR adding the concrete manager.
e7eac86
to
302b25d
Compare
Done |
Checked commits moolitayer/manageiq@62f873e~...302b25d with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0 |
This is the first item of ManageIQ/manageiq-providers-kubernetes#39