[Hawkular-dev] Generic Hawkular-UI in MiQ

[John Mazzitelli]

> I'd like to extend the idea that Heiko proposed.
> Generic UI is a great idea.
> But there is one more thing we can try to solve if we take this road -
> inventory collection (on MIQ side) and the hardcoded models. Right now we
> need to create designated db tables, migration scripts, hardcode upfront all
> the models. And it currently resides in miq core repo.
> What if in addition to dynamic/generic UI we could also shift the inventory
> collection to be dynamic, and reduce somehow the need in adding/hardcoding
> the models upfront?
> That, of course, depends not only on the challenges that John listed here,
> but also on whether Rails can easily enable to do so.

You could take a look at the RHQ data model. Not saying its 100% perfect (the recursive tables for resource config was brilliant but evil at the same time :-), but it was a generic data model that supported any resource type/resource (including custom ones customers just created themselves in their own agent plugins). So without adding any data tables we were able to support any resource type and any resource from hardware resources like CPUs and bare metal machines up to application servers, databases, and everything in between.

The problem with generic data models is that while one-size-fits-all is great most of the time, there are always those "one off" use-cases that you wish you could have your own data model for that type for whatever reason. Which is why I would say don't necessarily look to the RHQ data model as a solution, but as a example of what a generic data model could look like, hopefully with some improvements made to it.

> 
> 
> 
> 
> On Thu, May 25, 2017 at 4:43 AM, John Mazzitelli < mazz at redhat.com > wrote:
> 
> 
> 
> This is the infamous "sync" problem. We have been desperately trying to avoid
> this - it was very complex and hard to get right in RHQ. You did not mention
> sync'ing resources themselves, but once we go down this road, I suspect that
> will be next.
> 
> But of course anything is possible. I will say if we are to do this, it will
> involve a *major* change to the agent code because we purposefully did not
> design it to work like RHQ did. The RT metadata gets stored and updated, not
> at startup in one big synchronous block of processing, but rather at the
> time resource discovery occurs. It happens piece by piece, asynchronously,
> as individual resources are discovered. And it happens well after the agent
> has started.
> 
> ----- Original Message -----
> > 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 list
> hawkular-dev at lists.jboss.org
> https://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
>