<div dir="ltr"><div>First I must preface this with the information that I do not know how this is</div><div>going to be implemented on Hawkular-Inventory side, and am explaining with the</div><div>perspective of the consumer of that data on ManageIQ. The idea is to explain</div><div>how the Dynamic/Generic UI PoC might model Karaf servers when Hawkular starts</div><div>reporting on it, for that reason I'm also going to follow through my thought</div><div>process instead of just presenting the final solution.</div><div><br></div><div>This is more about how we could model the data internally than how to fetch and</div><div>process that data before presenting it to the API. Because of this, I'm not</div><div>going to tackle Views, because they are only supposed to be representation for</div><div>the Entities. With the entities defined, we can make any kind of</div><div>representations we want, and that depends more on what the UI requires than any</div><div>internal presentation of the data in objects.</div><div><br></div><div>Currently, at the Proof of Concept, we have this structure representing all the</div><div>reported entities:</div><div><br></div><div>* Entity (base class, never matched)</div><div> * MiddlewareResource</div><div> * MiddlewareServer</div><div> * WildFlyServer</div><div> * OperatingSystem</div><div> * JavaRuntime</div><div><br></div><div>Without implementing anything, the structure presented will match Karaf Servers</div><div>by default, by matching it to MiddlewareServer, and the resources it exposes</div><div>are matched to MiddlewareResources. OperatingSystem and JavaRuntime should be</div><div>the same.</div><div><br></div><div>Going forward, we need to map the servers, which we do by subclassing</div><div>MiddlewareServer, and we have KarafServer. Next step is going to the resources,</div><div>which we can implement like this:</div><div><br></div><div>* CamelContext < MiddlewareResource</div><div> * Routes (CamelRoute)</div><div> * Consumers (CamelConsumer)</div><div> * State</div><div><br></div><div>* CamelRoute < MiddlewareResource</div><div> * URI</div><div> * State</div><div><br></div><div>* CamelConsumer < MiddlewareResource</div><div> * URI</div><div> * Route</div><div> * State</div><div><br></div><div>* CamelProcessor < MiddlewareResource</div><div> * No Data?</div><div><br></div><div>Questions:</div><div><br></div><div>1. How is this supposed to be shown on the UI?</div><div><br></div><div>3. How is the relationship between context and routes/consumers is going to be</div><div> presented by Hawkular?</div><div><br></div><div>4. How is the relationship between consumers and routes going to be presented</div><div> by Hawkular?</div><div><br></div><div>5. For JVM memory collection, Mazz said that the information could be get</div><div> through JMX directly, how would that be presented on the inventory API?</div><div><br></div><div> Currently, for WildFly, this appears in the "JavaRuntime" resource, is this</div><div> going to be the same for Karaf servers?</div><div><br></div><div>6. Are the metrics for CamelRoutes, CamelConsumers, CamelProcessors and</div><div> CamelRoutes be presented directly onto themselves, or should their data be</div><div> aggregated in any way on the KarafServer?</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 31, 2017 at 1:08 PM, Heiko Rupp <span dir="ltr"><<a href="mailto:hrupp@redhat.com" target="_blank">hrupp@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Caina,<span class=""><br>
<br>
<br>
On 20 Jul 2017, at 22:29, Caina Costa wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></span>
It's great that you are making progress. There are still some<br>
missing pieces for me, but perhaps just because I didn't<br>
try the code.<br>
Before I go on, let me put a diagram in:<br>
<br>
<br>
In Blue are pieces that should not need any modification if<br>
a new type of Server is added. In the picture I have three servers<br>
Type A and Type B, which have their configuration for the<br>
resources they represent and report and send metrics about.<br>
They would now also get additional data (meta data) about<br>
the layout of those resources on the MiQ UI (Def A and B).<br>
So if I modify Def A, the way the UI is layouted in Layout A<br>
should change.<br>
<br>
There are now some extra definitions, that I want to briefly<br>
explain:<br>
In the current setup of the agent and inventory, each server of<br>
a given type (Type B) sends its own Inventory report and would<br>
also send its own version of the Definition, hence Def B and Def B'.<br>
<br>
What we could do it to now use Def* from the agent, but create<br>
(Hawkular-)server side definitions SDef* for that purpose that<br>
would then direct the layouting as Def A and so would do.<br>
But that is a bit of a 2ndary concern at the moment.<br>
<br>
I think what would be good if you could implement your current<br>
status end-to-end with a new type of server (something Fusy)<br>
including the definition file on Hawkular side and an actual rendered<br>
UI so that we can continue from there.<br>
<br>
Thanks<span class="HOEnZb"><font color="#888888"><br>
Heiko<br>
<br>
<br>
</font></span><br>______________________________<wbr>_________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a><br>
<br></blockquote></div><br></div>