1:30 p.m.
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/) 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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev