6:17 p.m.
Nice Caina! I think we can work with this :)
On May 25, 2017, at 11:30 AM, Caina Costa <cacosta(a)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(a)redhat.com
<mailto:hrupp@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 <mailto:hawkular-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev