On Mon, Jul 17, 2017 at 9:39 AM, Alissa Bonas <abonas@redhat.com> wrote:
1. a diagram that shows an example of architecture components and data format of entities (json/code/configuration) will help to understand the proposal.
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:
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.
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.
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")
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.
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:
entity = Entity.constantize(MiddlewareServer.first.data)
render json: View.for(entity)
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.On Mon, Jul 17, 2017 at 3:27 PM, Caina Costa <cacosta@redhat.com> wrote: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.So, in summary: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:MiddlewareServer > WildFlyServer > WildFly11ServerFor this example, let's say that MiddlewareServer includes only the summary, WildFlyServer includes metrics, and WildFly11Server includes power operations.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.On Mon, Jul 17, 2017 at 8:31 AM, Thomas Heute <theute@redhat.com> wrote:I just watched the recording, it was not clear to me the benefits it brings (or if it's just internal).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.Can you explain ?ThomasOn Thu, Jul 13, 2017 at 6:13 PM, Caina Costa <cacosta@redhat.com> wrote:As always, if you have any questions, please do not hesitate to get in touch. I'm available on IRC and e-mail.And the slides are attached.Hello guys,Thanks you all for joining the presentation, lots of great questions! For those of you that could not join, here's the recording:
https://bluejeans.com/s/hnR7@/