[Hawkular-dev] Dynamic UI PoC Presentation

[Caina Costa]

First I must preface this with the information that I do not know how this
is
going to be implemented on Hawkular-Inventory side, and am explaining with
the
perspective of the consumer of that data on ManageIQ. The idea is to explain
how the Dynamic/Generic UI PoC might model Karaf servers when Hawkular
starts
reporting on it, for that reason I'm also going to follow through my thought
process instead of just presenting the final solution.

This is more about how we could model the data internally than how to fetch
and
process that data before presenting it to the API. Because of this, I'm not
going to tackle Views, because they are only supposed to be representation
for
the Entities.  With the entities defined, we can make any kind of
representations we want, and that depends more on what the UI requires than
any
internal presentation of the data in objects.

Currently, at the Proof of Concept, we have this structure representing all
the
reported entities:

* Entity (base class, never matched)
  * MiddlewareResource
    * MiddlewareServer
      * WildFlyServer
    * OperatingSystem
    * JavaRuntime

Without implementing anything, the structure presented will match Karaf
Servers
by default, by matching it to MiddlewareServer, and the resources it exposes
are matched to MiddlewareResources. OperatingSystem and JavaRuntime should
be
the same.

Going forward, we need to map the servers, which we do by subclassing
MiddlewareServer, and we have KarafServer. Next step is going to the
resources,
which we can implement like this:

* CamelContext < MiddlewareResource
  * Routes (CamelRoute)
  * Consumers (CamelConsumer)
  * State

* CamelRoute < MiddlewareResource
  * URI
  * State

* CamelConsumer < MiddlewareResource
  * URI
  * Route
  * State

* CamelProcessor < MiddlewareResource
  * No Data?

Questions:

1. How is this supposed to be shown on the UI?

3. How is the relationship between context and routes/consumers is going to
be
   presented by Hawkular?

4. How is the relationship between consumers and routes going to be
presented
   by Hawkular?

5. For JVM memory collection, Mazz said that the information could be get
   through JMX directly, how would that be presented on the inventory API?

   Currently, for WildFly, this appears in the "JavaRuntime" resource, is
this
   going to be the same for Karaf servers?

6. Are the metrics for CamelRoutes, CamelConsumers, CamelProcessors and
   CamelRoutes be presented directly onto themselves, or should their data
be
   aggregated in any way on the KarafServer?


On Mon, Jul 31, 2017 at 1:08 PM, Heiko Rupp <hrupp at redhat.com> wrote:

> Hey Caina,
>
>
> On 20 Jul 2017, at 22:29, Caina Costa wrote:
>
> This is another update to the proof of concept, and today we are doing big
>> improvements to cover other parts of the representation that we did not
>> cover yet: fetching data from Hawkular, and turning that into
>> entities/views.
>>
>
> It's great that you are making progress. There are still some
> missing pieces for me, but perhaps just because I didn't
> try the code.
> Before I go on, let me put a diagram in:
>
>
> In Blue are pieces that should not need any modification if
> a new type of Server is added. In the picture I have three servers
> Type A and Type B, which have their configuration for the
> resources they represent and report and send metrics about.
> They would now also get additional data (meta data) about
> the layout of those resources on the MiQ UI (Def A and B).
> So if I modify Def A, the way the UI is layouted in Layout A
> should change.
>
> There are now some extra definitions, that I want to briefly
> explain:
> In the current setup of the agent and inventory, each server of
> a given type (Type B) sends its own Inventory report and would
> also send its own version of the Definition, hence Def B and Def B'.
>
> What we could do it to now use Def* from the agent, but create
> (Hawkular-)server side definitions SDef* for that purpose that
> would then direct the layouting as Def A and so would do.
> But that is a bit of a 2ndary concern at the moment.
>
> I think what would be good if you could implement your current
> status end-to-end with a new type of server (something Fusy)
> including the definition file on Hawkular side and an actual rendered
> UI so that we can continue from there.
>
> Thanks
>    Heiko
>
>
>
> _______________________________________________
> 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/20170801/07b5900d/attachment.html