[Hawkular-dev] Generic Hawkular-UI in MiQ

mike thompson mithomps at redhat.com
Wed Jul 5 19:17:13 EDT 2017


Nice Caina! I think we can work with this :)


> On May 25, 2017, at 11:30 AM, Caina Costa <cacosta at redhat.com> wrote:
> 
> 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.
> 
> There are some questions that I have:
> 
> * What kind of metadata are we talking about, is it static or more of schema-less data?
> * Are we talking only about showing the data, or also editing, filtering and searching?
> * How should the backend present it to the frontend? As a normal controller or through an API?
> * In case we have more metadata in the future to be available for all entities, how should we migrate the older ones?
> * Is there a way to present JSON Schema (http://json-schema.org/ <http://json-schema.org/>) from the Agent to MiQ, or at least to have that defined before we start working on it?
> * 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?
> * 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:
> 
> { "capabilities": ["operations", "metrics"] }
> 
> And from that we should show the correct info/actions on the page.
> 
> 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.
> 
> On Thu, May 25, 2017 at 7:43 AM, Heiko W.Rupp <hrupp at redhat.com <mailto:hrupp at redhat.com>> wrote:
> On 25 May 2017, at 2:40, mike thompson wrote:
> >
> > From a MiQ UI perspective, we should be able to ‘map’ multiple
> > disparate structures into a canonical MiQ model that gets rendered in
> > the UI. The MiQ UI screens are just representing models so as long as
> > we just maintain consistent mappings into the canonical fields we
> > should be fine. Of course, we will probably have to add new generic
> > fields as new attributes arise, but that is expected.
> 
> I think what I forgot to mention is that in the .haml when
> you have
> 
> properties:
> - foo
> - bar
> - baz
> 
> it is also possible to compute that list via a method
> (under the hood, those lists are method calls anyway)
> 
> > This provides a more metadata style approach. It is a change of
> > direction, but we are changing things anyway with new technology
> > decisions.
> 
> The idea is to quickly get out support for new supported
> entities (e.g. Infinispan) by having the structure on the metadata.
> This also allows for the owners of the entities (Ispn-team) to
> provide the knowledge about the structure in the (agent)
> metadata without the need to also create MiQ code.
> 
> This does not prevent us from doing more specific screens
> later on for those entities. It is really meant to get initial
> support for those  in more quickly.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170705/09dad2b8/attachment.html 


More information about the hawkular-dev mailing list