<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 25, 2017 at 7:01 AM, Jay Shaughnessy <span dir="ltr"><<a href="mailto:jshaughn@redhat.com" target="_blank">jshaughn@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<br>
<font face="Calibri">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.</font></div></blockquote><div>+1 </div><div>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".</div><div><br></div><div>We could use the RT or product name from each server and use a mapping (or hierarchy?) to decide how to render it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><div><div class="gmail-h5"><br>
<br>
<div class="gmail-m_5789446848740881945moz-cite-prefix">On 5/24/2017 11:54 AM, Heiko W.Rupp
wrote:<br>
</div>
<blockquote type="cite">
<pre>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]
<a class="gmail-m_5789446848740881945moz-txt-link-freetext" href="https://github.com/pilhuhn/misc_writing/blob/master/HowToWriteAnRhqPlugin/example.adoc#enhancing-the-plugin" target="_blank">https://github.com/pilhuhn/<wbr>misc_writing/blob/master/<wbr>HowToWriteAnRhqPlugin/example.<wbr>adoc#enhancing-the-plugin</a>
[2]
<a class="gmail-m_5789446848740881945moz-txt-link-freetext" href="https://github.com/hawkular/hawkular-agent/blob/master/hawkular-javaagent/src/test/resources/real-config.yaml" target="_blank">https://github.com/hawkular/<wbr>hawkular-agent/blob/master/<wbr>hawkular-javaagent/src/test/<wbr>resources/real-config.yaml</a>
______________________________<wbr>_________________
hawkular-dev mailing list
<a class="gmail-m_5789446848740881945moz-txt-link-abbreviated" href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a>
<a class="gmail-m_5789446848740881945moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<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></div>