[Hawkular-dev] Generic Hawkular-UI in MiQ

[Josejulio Martinez Magana]

On Thu, May 25, 2017 at 7:01 AM, Jay Shaughnessy <jshaughn at redhat.com>
wrote:

>
> Do we really need to drive off an agent or server-side config?  Perhaps
> the UI config could be local to the UI, reflecting the resource types it
> needs to handle and the necessary meta-data.  Yes, it's disconnected from
> the RTs defined on the clients, but in reality those are pretty consistent
> for the types we render in the UI.  We could potentially contain some
> mapping rules to help handle special-cases.
>
+1
I think we should consider this option. The agent provides general
information about the server and we don't want to render every detail about
it. I guess we will end "customizing" a lot of the agent-driven-ui to have
it "right".

We could use the RT or product name from each server and use a mapping (or
hierarchy?) to decide how to render it.


>
>
> On 5/24/2017 11:54 AM, Heiko W.Rupp 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?
>
>
>
> [1] https://github.com/pilhuhn/misc_writing/blob/master/HowToWriteAnRhqPlugin/example.adoc#enhancing-the-plugin
> [2] https://github.com/hawkular/hawkular-agent/blob/master/hawkular-javaagent/src/test/resources/real-config.yaml
>
> _______________________________________________
> hawkular-dev mailing listhawkular-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170525/53e9ac48/attachment.html