<div dir="ltr">So, I did some research on the codebase for possible pain points for this change. It looks completely doable, albeit that's going to be quite a bit work to get it correctly. As for backend details, I've been thinking about having a "base" entity, provably something like MiddlewareEntity, which would have the fields in common for all entities as usual, as well as a "metadata" field exposed as a JSON, and then we can work from there to get everything else working.<div><br></div><div>There are some questions that I have:</div><div><br></div><div>* What kind of metadata are we talking about, is it static or more of schema-less data?</div><div>* Are we talking only about showing the data, or also editing, filtering and searching?</div><div>* How should the backend present it to the frontend? As a normal controller or through an API?</div><div>* In case we have more metadata in the future to be available for all entities, how should we migrate the older ones?</div><div>* Is there a way to present JSON Schema (<a href="http://json-schema.org/">http://json-schema.org/</a>) from the Agent to MiQ, or at least to have that defined before we start working on it?</div><div>* How are "capabilities" supposed to be shown to MiQ? Let's say, a server has the support on running operations, can we assume that this will be signaled somewhere to us?</div><div>* How much of the control on what MiQ can do should be available on miq-side and how much should be provided by the agent? Let's say, right now manageiq has the knowledge on whether a server is mutable or not, and based on that knowledge we decide if we should enable server operations or not. I don't think that's ideal, and in my mind the ideal case would be having something like that on the data:<br><br>{ "capabilities": ["operations", "metrics"] }<br><br>And from that we should show the correct info/actions on the page.</div><div><br></div><div>As a bottom point, I like this feature very much, as it can reduce the amount of info ManageIQ has to act upon, by moving responsibilities from it to the agent.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 25, 2017 at 7:43 AM, Heiko W.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"><span class="">On 25 May 2017, at 2:40, mike thompson wrote:<br>
><br>
> From a MiQ UI perspective, we should be able to ‘map’ multiple<br>
> disparate structures into a canonical MiQ model that gets rendered in<br>
> the UI. The MiQ UI screens are just representing models so as long as<br>
> we just maintain consistent mappings into the canonical fields we<br>
> should be fine. Of course, we will probably have to add new generic<br>
> fields as new attributes arise, but that is expected.<br>
<br>
</span>I think what I forgot to mention is that in the .haml when<br>
you have<br>
<br>
properties:<br>
- foo<br>
- bar<br>
- baz<br>
<br>
it is also possible to compute that list via a method<br>
(under the hood, those lists are method calls anyway)<br>
<span class=""><br>
> This provides a more metadata style approach. It is a change of<br>
> direction, but we are changing things anyway with new technology<br>
> decisions.<br>
<br>
</span>The idea is to quickly get out support for new supported<br>
entities (e.g. Infinispan) by having the structure on the metadata.<br>
This also allows for the owners of the entities (Ispn-team) to<br>
provide the knowledge about the structure in the (agent)<br>
metadata without the need to also create MiQ code.<br>
<br>
This does not prevent us from doing more specific screens<br>
later on for those entities. It is really meant to get initial<br>
support for those in more quickly.<br>
<div class="HOEnZb"><div class="h5">______________________________<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>
</div></div></blockquote></div><br></div>