Adding status indication to entities on middleware topology

[miq-bot]

This is a placeholder to discuss what is the relevant field/work needed for each entity to have the status color indication to be displayed for each entity on the middleware topology.

@miq-bot add_label enhancement, providers/hawkular

Currently this is needed for:

• provider - (the relevant check/method is the authentication status)
• middleware_server
• middleware_deployment
• middleware_datasource
• middleware_destination (jms topic/queue)

cc @pilhuhn please add your thoughts here

---

This issue was moved to this repository from ManageIQ/manageiq#9033, originally opened by @abonas

[israel-hdez]

Right now, status is only resolved for servers and deployments.
I may work this in stages:

• Show status for servers and deployments in topology. Rendering status for servers and deployments in middleware topology manageiq-ui-classic#1461
• Change event_catcher to be able to "catch" up/down events in the metrics. Although, I don't know if it may be better to add a metrics worker for this. Extending event catcher and adding targeted refresh for availabilities #27
  • This would allow MiQ to update its data to better reflect the status of the entities.
• Do whatever changes are needed to resolve provider status.
• If there is any way to resolve status for datasources and destinations:
  • Fetch its status when refreshing inventory.
  • Show status in topology.
  • Change (again) event catcher to monitor status updates.

Regarding datasources and destinations/messagings I don't know if hawkular tracks their status in any metrics.

Also, with the ongoing discussion about making generic the Hawkular's UI part of MiQ, I'm not sure if I should work on this issue, because big changes may occur if that direction is taken.

cc @pilhuhn @abonas

[miq-bot]

@miq-bot Cannot apply the following label because they are not recognized: providers/hawkular

[miq-bot]

@miq-bot unrecognized command 'Cannot', ignoring...

Accepted commands are: add_label, assign, close_issue, move_issue, remove_label, rm_label, set_milestone

[israel-hdez]

🔁 That bot is talking with itself... 😂

[miq-bot]

@miq-bot unrecognized command 'unrecognized', ignoring...

Accepted commands are: add_label, assign, close_issue, move_issue, remove_label, rm_label, set_milestone

[abonas]

@israel-hdez I think it's worth to add this for servers at this point. And then we'll see :)

[israel-hdez]

Ok, I'm working on it.

[israel-hdez]

Hmm... Looks like the better way to deal with the second task is to add a MetricsCollectorWorker and leave untouched the EventCatcher.

Although I am unsure about the name, because it won't collect metrics but, instead, just watch specific metrics related to the status change of server/deployments and update MiQ inventory data accordingly. Perhaps, should it be InventoryMonitorWorker?

For now I will stick with MetricsCollectorWorker because it looks like a standard name. Please comment if anybody believe I should use another name that is more descriptive about what the worker will be doing.

[israel-hdez]

Regarding the second step about adding a worker to monitor statuses, I read a little more about how is implemented an EventCatcher. Looks like the standard pattern is to enqueue catched events to be further processed in EmsEvent here, but the use case needed in this issue will be off that pattern supporting my idea that EventCatcher is not a good place to do status monitoring.

So, I tried to add a MetricsCollectorWorker but the standard pattern for it is to inherit from a base MetricsCollectorWorker which is a "queue". If I use this, the worker would just sit there waiting for something to come into the queue, which will never happen because there is nothing to feed that queue. So, I also don't see this as a viable option.

The last option I can think of is just to add a custom InventoryMonitorWorker inheriting from raw MiqWorker. Any advice against this? Or is there some other kind of standard worker that I could use for this?

cc @abonas

[abonas]

Regarding the second step about adding a worker to monitor statuses, I read a little more about how is implemented an EventCatcher. Looks like the standard pattern is to enqueue catched events to be further processed in EmsEvent here, but the use case needed in this issue will be off that pattern supporting my idea that EventCatcher is not a good place to do status monitoring.

So, I tried to add a MetricsCollectorWorker but the standard pattern for it is to inherit from a base MetricsCollectorWorker which is a "queue". If I use this, the worker would just sit there waiting for something to come into the queue, which will never happen because there is nothing to feed that queue. So, I also don't see this as a viable option.

The last option I can think of is just to add a custom InventoryMonitorWorker inheriting from raw MiqWorker. Any advice against this? Or is there some other kind of standard worker that I could use for this?

cc @abonas

please check with miq core team

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 6 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions!