Re: [Hawkular-dev] Generic Hawkular-UI in MiQ

On May 24, 2017, at 8:54 AM, Heiko W.Rupp <hrupp(a)redhat.com&gt; wrote: Hey, the current way we implement the Hawkular-part of the MiQ ui is static, where we write .haml files that show what properties and relations to show. Basically for each resource type one such page exists. Adding a new kind of server like e.g. Apache Tomcat would need to add a ton new .haml files. In RHQ we had a pretty generic UI that was driven off of the metadata inside the plugin descriptor. If a resource type had <operation> elements, then the UI showed the operations tab. Similar for the list of metrics or the Events tab etc. Also for the resource configuration, the tab and the list of configuration properties was driven off of the plugin descriptor. See also [1]. The idea is now to apply the same mechanics to the ManageIQ UI so that the resource type definitions coming from the agent can drive the UI. We most probably need to extend the current config [2] to show - what is shown by default - how relations are to be shown - which properties should be grouped together The agent would store those in the resource type, which MiQ can pull and build the UI from those definitions. There is currently a rough spot: how to deal with one / more "competing" WildFly RTs? In RHQ we had the one canonical definition of a resource type. Now each agent could send a different one. While technically we can work with that, it may be confusing if 2 WF-standalone look different. It will not happen often though - especially in container-land, where the config is "backed into the image". I wonder if we should change this way of inventory a bit to be similar to RHQ (but more simple): - RT definition is done on the server - agent asks for the RT definition on 1st start - MiQ also gets the RT definition from the server. With Inventory.v3 this may mean that some startup code needs to populate RTs and probably periodically refresh them. Thoughts?

From a MiQ UI perspective, we should be able to ‘map’ multiple disparate structures into a canonical MiQ model that gets rendered in the UI. The MiQ UI screens are just representing models so as long as we just maintain consistent mappings into the canonical fields we should be fine. Of course, we will probably have to add new generic fields as new attributes arise, but that is expected. Editing those fields with proper validations will be a bit trickier as context is required (but still possible).

[1] https://github.com/pilhuhn/misc_writing/blob/master/HowToWriteAnRhqPlugin... [2] https://github.com/hawkular/hawkular-agent/blob/master/hawkular-javaagent... _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev