<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Nice Caina! I think we can work with this :)<div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 25, 2017, at 11:30 AM, Caina Costa <<a href="mailto:cacosta@redhat.com" class="">cacosta@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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 class=""><br class=""></div><div class="">There are some questions that I have:</div><div class=""><br class=""></div><div class="">* What kind of metadata are we talking about, is it static or more of schema-less data?</div><div class="">* Are we talking only about showing the data, or also editing, filtering and searching?</div><div class="">* How should the backend present it to the frontend? As a normal controller or through an API?</div><div class="">* In case we have more metadata in the future to be available for all entities, how should we migrate the older ones?</div><div class="">* Is there a way to present JSON Schema (<a href="http://json-schema.org/" class="">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 class="">* 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 class="">* 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 class=""><br class="">{ "capabilities": ["operations", "metrics"] }<br class=""><br class="">And from that we should show the correct info/actions on the page.</div><div class=""><br class=""></div><div class="">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 class=""><div class="gmail_quote">On Thu, May 25, 2017 at 7:43 AM, Heiko W.Rupp <span dir="ltr" class=""><<a href="mailto:hrupp@redhat.com" target="_blank" class="">hrupp@redhat.com</a>></span> wrote:<br class=""><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 class="">
><br class="">
> From a MiQ UI perspective, we should be able to ‘map’ multiple<br class="">
> disparate structures into a canonical MiQ model that gets rendered in<br class="">
> the UI. The MiQ UI screens are just representing models so as long as<br class="">
> we just maintain consistent mappings into the canonical fields we<br class="">
> should be fine. Of course, we will probably have to add new generic<br class="">
> fields as new attributes arise, but that is expected.<br class="">
<br class="">
</span>I think what I forgot to mention is that in the .haml when<br class="">
you have<br class="">
<br class="">
properties:<br class="">
- foo<br class="">
- bar<br class="">
- baz<br class="">
<br class="">
it is also possible to compute that list via a method<br class="">
(under the hood, those lists are method calls anyway)<br class="">
<span class=""><br class="">
> This provides a more metadata style approach. It is a change of<br class="">
> direction, but we are changing things anyway with new technology<br class="">
> decisions.<br class="">
<br class="">
</span>The idea is to quickly get out support for new supported<br class="">
entities (e.g. Infinispan) by having the structure on the metadata.<br class="">
This also allows for the owners of the entities (Ispn-team) to<br class="">
provide the knowledge about the structure in the (agent)<br class="">
metadata without the need to also create MiQ code.<br class="">
<br class="">
This does not prevent us from doing more specific screens<br class="">
later on for those entities. It is really meant to get initial<br class="">
support for those in more quickly.<br class="">
<div class="HOEnZb"><div class="h5">______________________________<wbr class="">_________________<br class="">
hawkular-dev mailing list<br class="">
<a href="mailto:hawkular-dev@lists.jboss.org" class="">hawkular-dev@lists.jboss.org</a><br class="">
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank" class="">https://lists.jboss.org/<wbr class="">mailman/listinfo/hawkular-dev</a><br class="">
</div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">hawkular-dev mailing list<br class=""><a href="mailto:hawkular-dev@lists.jboss.org" class="">hawkular-dev@lists.jboss.org</a><br class="">https://lists.jboss.org/mailman/listinfo/hawkular-dev<br class=""></div></blockquote></div><br class=""></div></body></html>