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

Add monitoring manager #15354

Merged
merged 2 commits into from
Jul 6, 2017
Merged

Conversation

moolitayer
Copy link

@moolitayer moolitayer commented Jun 12, 2017

This is the first item of ManageIQ/manageiq-providers-kubernetes#39

@miq-bot miq-bot added the wip label Jun 12, 2017
@moolitayer moolitayer force-pushed the add_monitoring_manager branch from 1d8b26d to d6f6a81 Compare June 13, 2017 15:33
@moolitayer moolitayer changed the title [WIP] Add monitoring manager Add monitoring manager Jun 13, 2017
@miq-bot miq-bot removed the wip label Jun 13, 2017
@moolitayer moolitayer changed the title Add monitoring manager [WIP] Add monitoring manager Jun 13, 2017
@miq-bot miq-bot added the wip label Jun 13, 2017
@moolitayer moolitayer force-pushed the add_monitoring_manager branch from d6f6a81 to c9ed7a3 Compare June 13, 2017 17:19
@moolitayer moolitayer changed the title [WIP] Add monitoring manager Add monitoring manager Jun 13, 2017
@moolitayer
Copy link
Author

@simon3z @blomquisg @Ladas please take a look

@miq-bot miq-bot removed the wip label Jun 13, 2017
class MonitoringManager < BaseManager
class << model_name
def route_key
"ems_monitoring"
Copy link
Author

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
Copy link
Contributor

@Ladas Ladas Jun 14, 2017

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 :-)

@Ladas
Copy link
Contributor

Ladas commented Jun 14, 2017

@miq-bot assign @blomquisg

looks good in overall, just need the specs fixed

@moolitayer
Copy link
Author

Thanks @Ladas I'll probably have a few more changes to this PR once I finish the event collection that uses the new managers.

@miq-bot
Copy link
Member

miq-bot commented Jun 19, 2017

This pull request is not mergeable. Please rebase and repush.

@moolitayer moolitayer force-pushed the add_monitoring_manager branch from c9ed7a3 to 14fc6b1 Compare June 27, 2017 10:03
@moolitayer
Copy link
Author

@Ladas @cben I think this is ready can you please review this?

@moolitayer moolitayer force-pushed the add_monitoring_manager branch 6 times, most recently from 03fd6d6 to e600b4d Compare June 28, 2017 13:08
@moolitayer
Copy link
Author

@Ladas @cben @simon3z please review

@moolitayer moolitayer force-pushed the add_monitoring_manager branch from e600b4d to 76d1251 Compare June 28, 2017 13:14
extend ActiveSupport::Concern

included do
# TODO: why is this relation needed ? why is the inheritors relation no enough?
Copy link
Contributor

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.

Copy link
Author

@moolitayer moolitayer Jun 29, 2017

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

Copy link
Author

Choose a reason for hiding this comment

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

removing for now

@@ -35,6 +35,7 @@
- ems-type:gce_network
- ems-type:hawkular
- ems-type:hawkular_datawarehouse
- ems-type:monitoring
Copy link
Contributor

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"?

Copy link
Author

@moolitayer moolitayer Jul 3, 2017

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

Copy link
Contributor

@simon3z simon3z Jul 3, 2017

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.

Copy link
Author

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:

#15506

Copy link
Author

@moolitayer moolitayer Jul 4, 2017

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]

def self.leaf_subclasses
descendants.select { |d| d.subclasses.empty? }
end

@moolitayer
Copy link
Author

There is a test failure[1] that does not seem related, restarting...

[1] ./spec/models/miq_report_spec.rb:151

@moolitayer
Copy link
Author

@simon3z please take a look

@simon3z
Copy link
Contributor

simon3z commented Jul 5, 2017

LGTM 👍 cc @blomquisg

@moolitayer
Copy link
Author

I'm seeing spec/models/miq_report_spec.rb:151 failing on master locally.

@@ -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)
Copy link
Member

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?

Copy link
Author

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"?

👍

Copy link
Author

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.

@moolitayer moolitayer force-pushed the add_monitoring_manager branch 3 times, most recently from 767a270 to e7eac86 Compare July 6, 2017 07:13
@@ -0,0 +1,21 @@
module HasMonitoringManagerMixin
Copy link
Member

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.

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 😢

Copy link
Author

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.

@moolitayer moolitayer force-pushed the add_monitoring_manager branch from e7eac86 to 302b25d Compare July 6, 2017 13:14
@moolitayer
Copy link
Author

I should probably change ensure_manager to ensure_X_manager.

Done

@miq-bot
Copy link
Member

miq-bot commented Jul 6, 2017

Checked commits moolitayer/manageiq@62f873e~...302b25d with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0
7 files checked, 0 offenses detected
Everything looks fine. ⭐

@blomquisg blomquisg merged commit fa18025 into ManageIQ:master Jul 6, 2017
@blomquisg blomquisg added this to the Sprint 64 Ending Jul 10, 2017 milestone Jul 6, 2017
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.

7 participants