OK, I can certainly see the advantage of being able to add to or update our supported entities without requiring changes to MIQ.  As Mazz said, it's a throwback to RHQ where persistence and UI was generically implemented.  The question is whether we can do something similar but more simple. It's not a small undertaking to convert to a config-driven UI, especially within the confines of MIQ.  My suggestion to have the UI-config differ from the agent config was motivated by a few things:

On the downside, it would mean keeping another config up to date and having the server provide it in some way to the gem/ui.  It's also not clear to me MIQ will green-light a generic approach to the db-tables.  When I tried to do some generic things early on it was rejected in favor of explicit fields and maintaining consistency with the way things were being done elsewhere.  Note that there are hooks with events and alerts, and maybe metrics, that would likely need to be revisited if we move to a more generic approach to the tables.


On 5/26/2017 9:25 AM, Heiko W.Rupp wrote:
On 26 May 2017, at 5:58, Josejulio Martinez Magana wrote:


Do we really need to drive off an agent or server-side config?  Perhaps

+1
I think we should consider this option. The agent provides general

I am not married to the agent providing this metadata, which
is shown by the "or on the server" part ;-)

Driving the UI from metadata on the Hawkular-services
side allows us to add support for new kinds of servers
- outside of MiQ release cycles
- by the people that write those servers without them becoming MiQ experts

Also issues like e.g. a missing property can be fixed on the H-S
side by adding this to the metdata.
_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev