<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 17, 2017 at 9:39 AM, Alissa Bonas <span dir="ltr"><<a href="mailto:abonas@redhat.com" target="_blank">abonas@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">1. a diagram that shows an example of
architecture components and data format of entities (json/code/configuration) will help to understand the proposal.<br></div></blockquote><div><br><img src="cid:ii_j587dckw0_15d50cc1dda7b13c" width="565" height="78"><br><br></div><div>This is an example of an Entity hierarchy, it shows what kind of entities we can create, as well as other patterns that we can use. The farther the key is from Entity, the more specialized it is, which means that the .applicable? method on those are a lot more picky on what kind of data it matches to. Views follow the same hierarchy and the engine matches the same way, and the first defined view is used, so let's say:<br><br></div><div>If we have a WildflyDomainControllerServer to render, first it will try to find WildFlyDomainControllerServerView, then WildFlyDomainServerView, then WildFlyServerView, then WildFlyServerBaseView, then ServerView. That means that adding new entities are not going to break the views being used.<br></div><div><br></div><div>Also, WildFlyServerBase is an abstract entity, in the sense that it only provides implementation, and is not to be matched. This can be achieved by setting .applicable? to return false. Entities are just normal ruby objects, there is nothing special about them, they just need to answer to the .applicable? method and receive 1 argument in its initializer.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">What
I mean is - which component should define/work with which format for the
example entities? what should be defined on hawkular side, what is
fetched and defined in ruby gem, what parts are defined and how they are processed in
miq ui, what parts in miq server + how does that work (or not :)) with
persisting objects in miq, etc. Can/should 2 completely different entities (such as middleware server and a deployment) use your proposal, given that they might have some similar common fields? (for example, "name", "status")<br></div></blockquote><div><br></div><div>Entities define the "canonical truth" of the responses from the server, and views define how to represent them as JSON. They don't tackle how we're going to present data, and not how to fetch them.<br><br></div><div>To persist data on MiQ: this PoC does not take any action on persisting stuff, it only cares about representation. To do that, we just need a new JSON field on every middleware table, to save the response from the server, and then we can use it. Something like this:<br><br></div><div>entity = Entity.constantize(MiddlewareServer.first.data)<br></div><div>render json: View.for(entity)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br>2. I noticed that the discussion moved to jbmc list although it
originated in hawkular-dev. the tech discussion is definitely more suitable in hawkular-dev as a continue to the original thread on the topic.<div><div class="h5"><br><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 17, 2017 at 3:27 PM, Caina Costa <span dir="ltr"><<a href="mailto:cacosta@redhat.com" target="_blank">cacosta@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 dir="ltr"><div><div><div><div>Yes, that's exactly what it does, with some caveats: we have a hierarchy of server types, as in, we first have to implement a generic server type that implements the default attributes to all the servers. From there, we can subclass for more specific server types, and the view/entity runtime takes care of match the hawkular data with the defined entities. So let's say we have a hierarchy like that:<br><br></div>MiddlewareServer > WildFlyServer > WildFly11Server<br><br></div><div>For this example, let's say that MiddlewareServer includes only the summary, WildFlyServer includes metrics, and WildFly11Server includes power operations.<br></div><div><br></div>When matching the data with Entity.constantize(data), we match first the more specialized server, so WildFly11Server, and then WildFlyServer, then the more generic MiddlewareServer. This is automatic on the runtime, and if we add new server types, it will try to match in the reverse of the order provided, first the most specific, then going forward for less specific entities.<br><br></div>So, in summary:<br><br></div>It does enable us to add new server types with no code change on the ManageIQ side, by providing more generic interfaces that we can match upon, which means that while we might not have all information by default, we will have a representation that makes sense. It also enables us to expand new server types easily with small changes.<br><div><div><div><div><div><br><br></div></div></div></div></div></div><div class="m_7957631066895083803gmail-HOEnZb"><div class="m_7957631066895083803gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 17, 2017 at 8:31 AM, Thomas Heute <span dir="ltr"><<a href="mailto:theute@redhat.com" target="_blank">theute@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 dir="ltr">I just watched the recording, it was not clear to me the benefits it brings (or if it's just internal).<div><br></div><div>I was hoping to see how one can add a new server type with no code change on the ManageIQ side, maybe I misinterpreted the current work.</div><div><br></div><div>Can you explain ?</div><span class="m_7957631066895083803gmail-m_3028710287863713391HOEnZb"><font color="#888888"><div><br></div><div>Thomas</div></font></span></div><div class="m_7957631066895083803gmail-m_3028710287863713391HOEnZb"><div class="m_7957631066895083803gmail-m_3028710287863713391h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 13, 2017 at 6:13 PM, Caina Costa <span dir="ltr"><<a href="mailto:cacosta@redhat.com" target="_blank">cacosta@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 dir="ltr"><div><div><div>Hello guys,<br><br></div>Thanks you all for joining the presentation, lots of great questions! For those of you that could not join, here's the recording:<br><br><a href="https://bluejeans.com/s/hnR7@/" target="_blank">https://bluejeans.com/s/hnR7@/</a><br><br></div>And the slides are attached.<br><br></div>As always, if you have any questions, please do not hesitate to get in touch. I'm available on IRC and e-mail.<br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div>