10:54 a.m.
Hey,
the current way we implement the Hawkular-part of the MiQ ui is static,
where we write .haml files that show what properties and relations to
show.
Basically for each resource type one such page exists.
Adding a new kind of server like e.g. Apache Tomcat would need to add
a ton new .haml files.
In RHQ we had a pretty generic UI that was driven off of the metadata
inside the plugin descriptor. If a resource type had <operation>
elements,
then the UI showed the operations tab. Similar for the list of metrics
or the Events tab etc. Also for the resource configuration, the tab and
the
list of configuration properties was driven off of the plugin
descriptor.
See also [1].
The idea is now to apply the same mechanics to the ManageIQ UI so that
the resource type definitions coming from the agent can drive the UI.
We most probably need to extend the current config [2] to show
- what is shown by default
- how relations are to be shown
- which properties should be grouped together
The agent would store those in the resource type, which MiQ
can pull and build the UI from those definitions.
There is currently a rough spot: how to deal with one / more "competing"
WildFly RTs?
In RHQ we had the one canonical definition of a
resource type. Now each agent could send a different one. While
technically we can
work with that, it may be confusing if 2 WF-standalone look different.
It will not happen
often though - especially in container-land, where the config is "backed
into the image".
I wonder if we should change this way of inventory a bit to be similar
to RHQ (but more
simple):
- RT definition is done on the server
- agent asks for the RT definition on 1st start
- MiQ also gets the RT definition from the server.
With Inventory.v3 this may mean that some startup code needs to populate
RTs
and probably periodically refresh them.
Thoughts?
[1]
https://github.com/pilhuhn/misc_writing/blob/master/HowToWriteAnRhqPlugin...
[2]
https://github.com/hawkular/hawkular-agent/blob/master/hawkular-javaagent...
7:40 p.m.
On May 24, 2017, at 8:54 AM, Heiko W.Rupp <hrupp(a)redhat.com>
wrote:
Hey,
the current way we implement the Hawkular-part of the MiQ ui is static,
where we write .haml files that show what properties and relations to
show.
Basically for each resource type one such page exists.
Adding a new kind of server like e.g. Apache Tomcat would need to add
a ton new .haml files.
In RHQ we had a pretty generic UI that was driven off of the metadata
inside the plugin descriptor. If a resource type had <operation>
elements,
then the UI showed the operations tab. Similar for the list of metrics
or the Events tab etc. Also for the resource configuration, the tab and
the
list of configuration properties was driven off of the plugin
descriptor.
See also [1].
The idea is now to apply the same mechanics to the ManageIQ UI so that
the resource type definitions coming from the agent can drive the UI.
We most probably need to extend the current config [2] to show
- what is shown by default
- how relations are to be shown
- which properties should be grouped together
The agent would store those in the resource type, which MiQ
can pull and build the UI from those definitions.
There is currently a rough spot: how to deal with one / more "competing"
WildFly RTs?
In RHQ we had the one canonical definition of a
resource type. Now each agent could send a different one. While
technically we can
work with that, it may be confusing if 2 WF-standalone look different.
It will not happen
often though - especially in container-land, where the config is "backed
into the image".
I wonder if we should change this way of inventory a bit to be similar
to RHQ (but more
simple):
- RT definition is done on the server
- agent asks for the RT definition on 1st start
- MiQ also gets the RT definition from the server.
With Inventory.v3 this may mean that some startup code needs to populate
RTs
and probably periodically refresh them.
Thoughts?
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. Editing those fields with
proper validations will be a bit trickier as context is required (but still possible).
This provides a more metadata style approach. It is a change of direction, but we are
changing things anyway with new technology decisions.
[1]
https://github.com/pilhuhn/misc_writing/blob/master/HowToWriteAnRhqPlugin...
[2]
https://github.com/hawkular/hawkular-agent/blob/master/hawkular-javaagent...
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
5:43 a.m.
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.
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
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
8:43 p.m.
This is the infamous "sync" problem. We have been desperately trying to avoid
this - it was very complex and hard to get right in RHQ. You did not mention sync'ing
resources themselves, but once we go down this road, I suspect that will be next.
But of course anything is possible. I will say if we are to do this, it will involve a
*major* change to the agent code because we purposefully did not design it to work like
RHQ did. The RT metadata gets stored and updated, not at startup in one big synchronous
block of processing, but rather at the time resource discovery occurs. It happens piece by
piece, asynchronously, as individual resources are discovered. And it happens well after
the agent has started.
----- Original Message -----
Hey,
the current way we implement the Hawkular-part of the MiQ ui is static,
where we write .haml files that show what properties and relations to
show.
Basically for each resource type one such page exists.
Adding a new kind of server like e.g. Apache Tomcat would need to add
a ton new .haml files.
In RHQ we had a pretty generic UI that was driven off of the metadata
inside the plugin descriptor. If a resource type had <operation>
elements,
then the UI showed the operations tab. Similar for the list of metrics
or the Events tab etc. Also for the resource configuration, the tab and
the
list of configuration properties was driven off of the plugin
descriptor.
See also [1].
The idea is now to apply the same mechanics to the ManageIQ UI so that
the resource type definitions coming from the agent can drive the UI.
We most probably need to extend the current config [2] to show
- what is shown by default
- how relations are to be shown
- which properties should be grouped together
The agent would store those in the resource type, which MiQ
can pull and build the UI from those definitions.
There is currently a rough spot: how to deal with one / more "competing"
WildFly RTs?
In RHQ we had the one canonical definition of a
resource type. Now each agent could send a different one. While
technically we can
work with that, it may be confusing if 2 WF-standalone look different.
It will not happen
often though - especially in container-land, where the config is "backed
into the image".
I wonder if we should change this way of inventory a bit to be similar
to RHQ (but more
simple):
- RT definition is done on the server
- agent asks for the RT definition on 1st start
- MiQ also gets the RT definition from the server.
With Inventory.v3 this may mean that some startup code needs to populate
RTs
and probably periodically refresh them.
Thoughts?
[1]
https://github.com/pilhuhn/misc_writing/blob/master/HowToWriteAnRhqPlugin...
[2]
https://github.com/hawkular/hawkular-agent/blob/master/hawkular-javaagent...
6:51 a.m.
I'd like to extend the idea that Heiko proposed.
Generic UI is a great idea.
But there is one more thing we can try to solve if we take this road -
inventory collection (on MIQ side) and the hardcoded models. Right now we
need to create designated db tables, migration scripts, hardcode upfront
all the models. And it currently resides in miq core repo.
What if in addition to dynamic/generic UI we could also shift the inventory
collection to be dynamic, and reduce somehow the need in adding/hardcoding
the models upfront?
That, of course, depends not only on the challenges that John listed here,
but also on whether Rails can easily enable to do so.
On Thu, May 25, 2017 at 4:43 AM, John Mazzitelli <mazz(a)redhat.com> wrote:
This is the infamous "sync" problem. We have been desperately trying to
avoid this - it was very complex and hard to get right in RHQ. You did not
mention sync'ing resources themselves, but once we go down this road, I
suspect that will be next.
But of course anything is possible. I will say if we are to do this, it
will involve a *major* change to the agent code because we purposefully did
not design it to work like RHQ did. The RT metadata gets stored and
updated, not at startup in one big synchronous block of processing, but
rather at the time resource discovery occurs. It happens piece by piece,
asynchronously, as individual resources are discovered. And it happens well
after the agent has started.
----- Original Message -----
> Hey,
>
> the current way we implement the Hawkular-part of the MiQ ui is static,
> where we write .haml files that show what properties and relations to
> show.
> Basically for each resource type one such page exists.
> Adding a new kind of server like e.g. Apache Tomcat would need to add
> a ton new .haml files.
>
> In RHQ we had a pretty generic UI that was driven off of the metadata
> inside the plugin descriptor. If a resource type had <operation>
> elements,
> then the UI showed the operations tab. Similar for the list of metrics
> or the Events tab etc. Also for the resource configuration, the tab and
> the
> list of configuration properties was driven off of the plugin
> descriptor.
> See also [1].
>
> The idea is now to apply the same mechanics to the ManageIQ UI so that
> the resource type definitions coming from the agent can drive the UI.
>
> We most probably need to extend the current config [2] to show
> - what is shown by default
> - how relations are to be shown
> - which properties should be grouped together
>
> The agent would store those in the resource type, which MiQ
> can pull and build the UI from those definitions.
>
> There is currently a rough spot: how to deal with one / more "competing"
> WildFly RTs?
> In RHQ we had the one canonical definition of a
> resource type. Now each agent could send a different one. While
> technically we can
> work with that, it may be confusing if 2 WF-standalone look different.
> It will not happen
> often though - especially in container-land, where the config is "backed
> into the image".
>
> I wonder if we should change this way of inventory a bit to be similar
> to RHQ (but more
> simple):
> - RT definition is done on the server
> - agent asks for the RT definition on 1st start
> - MiQ also gets the RT definition from the server.
> With Inventory.v3 this may mean that some startup code needs to populate
> RTs
> and probably periodically refresh them.
>
> Thoughts?
>
>
>
> [1]
> https://github.com/pilhuhn/misc_writing/blob/master/HowToWri
teAnRhqPlugin/example.adoc#enhancing-the-plugin
> [2]
> https://github.com/hawkular/hawkular-agent/blob/master/hawku
lar-javaagent/src/test/resources/real-config.yaml
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
4:33 p.m.
I'd like to extend the idea that Heiko proposed.
Generic UI is a great idea.
But there is one more thing we can try to solve if we take this road -
inventory collection (on MIQ side) and the hardcoded models. Right now we
need to create designated db tables, migration scripts, hardcode upfront all
the models. And it currently resides in miq core repo.
What if in addition to dynamic/generic UI we could also shift the inventory
collection to be dynamic, and reduce somehow the need in adding/hardcoding
the models upfront?
That, of course, depends not only on the challenges that John listed here,
but also on whether Rails can easily enable to do so.
You could take a look at the RHQ data model. Not saying its 100% perfect (the recursive
tables for resource config was brilliant but evil at the same time :-), but it was a
generic data model that supported any resource type/resource (including custom ones
customers just created themselves in their own agent plugins). So without adding any data
tables we were able to support any resource type and any resource from hardware resources
like CPUs and bare metal machines up to application servers, databases, and everything in
between.
The problem with generic data models is that while one-size-fits-all is great most of the
time, there are always those "one off" use-cases that you wish you could have
your own data model for that type for whatever reason. Which is why I would say don't
necessarily look to the RHQ data model as a solution, but as a example of what a generic
data model could look like, hopefully with some improvements made to it.
On Thu, May 25, 2017 at 4:43 AM, John Mazzitelli < mazz(a)redhat.com > wrote:
This is the infamous "sync" problem. We have been desperately trying to avoid
this - it was very complex and hard to get right in RHQ. You did not mention
sync'ing resources themselves, but once we go down this road, I suspect that
will be next.
But of course anything is possible. I will say if we are to do this, it will
involve a *major* change to the agent code because we purposefully did not
design it to work like RHQ did. The RT metadata gets stored and updated, not
at startup in one big synchronous block of processing, but rather at the
time resource discovery occurs. It happens piece by piece, asynchronously,
as individual resources are discovered. And it happens well after the agent
has started.
----- Original Message -----
> Hey,
>
> the current way we implement the Hawkular-part of the MiQ ui is static,
> where we write .haml files that show what properties and relations to
> show.
> Basically for each resource type one such page exists.
> Adding a new kind of server like e.g. Apache Tomcat would need to add
> a ton new .haml files.
>
> In RHQ we had a pretty generic UI that was driven off of the metadata
> inside the plugin descriptor. If a resource type had <operation>
> elements,
> then the UI showed the operations tab. Similar for the list of metrics
> or the Events tab etc. Also for the resource configuration, the tab and
> the
> list of configuration properties was driven off of the plugin
> descriptor.
> See also [1].
>
> The idea is now to apply the same mechanics to the ManageIQ UI so that
> the resource type definitions coming from the agent can drive the UI.
>
> We most probably need to extend the current config [2] to show
> - what is shown by default
> - how relations are to be shown
> - which properties should be grouped together
>
> The agent would store those in the resource type, which MiQ
> can pull and build the UI from those definitions.
>
> There is currently a rough spot: how to deal with one / more "competing"
> WildFly RTs?
> In RHQ we had the one canonical definition of a
> resource type. Now each agent could send a different one. While
> technically we can
> work with that, it may be confusing if 2 WF-standalone look different.
> It will not happen
> often though - especially in container-land, where the config is "backed
> into the image".
>
> I wonder if we should change this way of inventory a bit to be similar
> to RHQ (but more
> simple):
> - RT definition is done on the server
> - agent asks for the RT definition on 1st start
> - MiQ also gets the RT definition from the server.
> With Inventory.v3 this may mean that some startup code needs to populate
> RTs
> and probably periodically refresh them.
>
> Thoughts?
>
>
>
> [1]
>
https://github.com/pilhuhn/misc_writing/blob/master/HowToWriteAnRhqPlugin...
> [2]
>
https://github.com/hawkular/hawkular-agent/blob/master/hawkular-javaagent...
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
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
1:53 p.m.
On 25 May 2017, at 3:43, John Mazzitelli wrote:
This is the infamous "sync" problem. We have been
desperately trying
to avoid this - it was very complex and hard to get right in RHQ. You
did not mention sync'ing resources themselves, but once we go down
this road, I suspect that will be next.
I know about the sync issues in RHQ, and by avoiding this
we now have the different issue of possible inconsistencies
of RTs that should be equal.
What I was trying to indicate is to ensure that (at least the
base) properties of all resource types that say they are
"WildFly 10 standalone server" are the same.
But of course anything is possible. I will say if we are to do this,
it will involve a *major* change to the agent code because we
purposefully did not design it to work like RHQ did. The RT metadata
gets stored and updated, not at startup in one big synchronous block
of processing, but rather at the time resource discovery occurs. It
happens
Isn't / shouldn't the metadata (RTs, MTs) come from
standalone.xml / config.yml ? My understanding is that
the RTs (not the actual resources) should be the same
as long as the user does not change standalone.xml/config.yml.
In this case we could remove those metric-type-dmr and
resource-type-dmr (or what they are called) and pull them
from the server, where we feed them in once. The agent
can then cache them locally if it wants.
piece by piece, asynchronously, as individual resources are
discovered. And it happens well after the agent has started.
Resource discovery would continue to work as is. And no,
not resource syncing or even RT-syncing.
Just moving the Metadata from each agent into a common
place and have the agent get it from there instead from a
local file.
Also I believe that the wish to modify individual RTs in agents
is less there in a containerized world, where we provide a
base image that has all the RTs baked in.
Anyway - unifying the RTs this way or not, does not change
the general approach of providing metadata to dynamically
create the UI from the metadata.
7:01 a.m.
Do we really need to drive off an agent or server-side config? Perhaps
the UI config could be local to the UI, reflecting the resource types it
needs to handle and the necessary meta-data. Yes, it's disconnected
from the RTs defined on the clients, but in reality those are pretty
consistent for the types we render in the UI. We could potentially
contain some mapping rules to help handle special-cases.
On 5/24/2017 11:54 AM, Heiko W.Rupp wrote:
Hey,
the current way we implement the Hawkular-part of the MiQ ui is static,
where we write .haml files that show what properties and relations to
show.
Basically for each resource type one such page exists.
Adding a new kind of server like e.g. Apache Tomcat would need to add
a ton new .haml files.
In RHQ we had a pretty generic UI that was driven off of the metadata
inside the plugin descriptor. If a resource type had <operation>
elements,
then the UI showed the operations tab. Similar for the list of metrics
or the Events tab etc. Also for the resource configuration, the tab and
the
list of configuration properties was driven off of the plugin
descriptor.
See also [1].
The idea is now to apply the same mechanics to the ManageIQ UI so that
the resource type definitions coming from the agent can drive the UI.
We most probably need to extend the current config [2] to show
- what is shown by default
- how relations are to be shown
- which properties should be grouped together
The agent would store those in the resource type, which MiQ
can pull and build the UI from those definitions.
There is currently a rough spot: how to deal with one / more "competing"
WildFly RTs?
In RHQ we had the one canonical definition of a
resource type. Now each agent could send a different one. While
technically we can
work with that, it may be confusing if 2 WF-standalone look different.
It will not happen
often though - especially in container-land, where the config is "backed
into the image".
I wonder if we should change this way of inventory a bit to be similar
to RHQ (but more
simple):
- RT definition is done on the server
- agent asks for the RT definition on 1st start
- MiQ also gets the RT definition from the server.
With Inventory.v3 this may mean that some startup code needs to populate
RTs
and probably periodically refresh them.
Thoughts?
[1]
https://github.com/pilhuhn/misc_writing/blob/master/HowToWriteAnRhqPlugin...
[2]
https://github.com/hawkular/hawkular-agent/blob/master/hawkular-javaagent...
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
10:58 p.m.
On Thu, May 25, 2017 at 7:01 AM, Jay Shaughnessy <jshaughn(a)redhat.com>
wrote:
Do we really need to drive off an agent or server-side config? Perhaps
the UI config could be local to the UI, reflecting the resource types it
needs to handle and the necessary meta-data. Yes, it's disconnected from
the RTs defined on the clients, but in reality those are pretty consistent
for the types we render in the UI. We could potentially contain some
mapping rules to help handle special-cases.
+1
I think we should consider this option. The agent provides general
information about the server and we don't want to render every detail about
it. I guess we will end "customizing" a lot of the agent-driven-ui to have
it "right".
We could use the RT or product name from each server and use a mapping (or
hierarchy?) to decide how to render it.
On 5/24/2017 11:54 AM, Heiko W.Rupp wrote:
Hey,
the current way we implement the Hawkular-part of the MiQ ui is static,
where we write .haml files that show what properties and relations to
show.
Basically for each resource type one such page exists.
Adding a new kind of server like e.g. Apache Tomcat would need to add
a ton new .haml files.
In RHQ we had a pretty generic UI that was driven off of the metadata
inside the plugin descriptor. If a resource type had <operation>
elements,
then the UI showed the operations tab. Similar for the list of metrics
or the Events tab etc. Also for the resource configuration, the tab and
the
list of configuration properties was driven off of the plugin
descriptor.
See also [1].
The idea is now to apply the same mechanics to the ManageIQ UI so that
the resource type definitions coming from the agent can drive the UI.
We most probably need to extend the current config [2] to show
- what is shown by default
- how relations are to be shown
- which properties should be grouped together
The agent would store those in the resource type, which MiQ
can pull and build the UI from those definitions.
There is currently a rough spot: how to deal with one / more "competing"
WildFly RTs?
In RHQ we had the one canonical definition of a
resource type. Now each agent could send a different one. While
technically we can
work with that, it may be confusing if 2 WF-standalone look different.
It will not happen
often though - especially in container-land, where the config is "backed
into the image".
I wonder if we should change this way of inventory a bit to be similar
to RHQ (but more
simple):
- RT definition is done on the server
- agent asks for the RT definition on 1st start
- MiQ also gets the RT definition from the server.
With Inventory.v3 this may mean that some startup code needs to populate
RTs
and probably periodically refresh them.
Thoughts?
[1]
https://github.com/pilhuhn/misc_writing/blob/master/HowToWriteAnRhqPlugin...
[2]
https://github.com/hawkular/hawkular-agent/blob/master/hawkular-javaagent...
_______________________________________________
hawkular-dev mailing
listhawkular-dev@lists.jboss.orghttps://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
8:25 a.m.
On 26 May 2017, at 5:58, Josejulio Martinez Magana wrote:
> Do we really need to drive off an agent or server-side config?
Perhaps
+1
I think we should consider this option. The agent provides general
I am not married to the agent providing this metadata, which
is shown by the "or on the server" part ;-)
Driving the UI from metadata on the Hawkular-services
side allows us to add support for new kinds of servers
- outside of MiQ release cycles
- by the people that write those servers without them becoming MiQ experts
Also issues like e.g. a missing property can be fixed on the H-S
side by adding this to the metdata.
5:36 p.m.
So, I went ahead and created a PoC on what I mean could be done on the
rails side of things on the previous email:
https://github.com/cfcosta/dynamic-entity-poc , and specially this:
https://github.com/cfcosta/dynamic-entity-poc/commit/01df9ca6bdc0f9580845...
It has some advantages from what we have now:
* Entity objects are not dependant on ActiveRecord, so we can use them as
value objects anywhere we want.
* We can define some conditions on spawning objects, so that we can have,
lets say, MutableServer and ImmutableServer as different classes
What do you guys think?
On Fri, May 26, 2017 at 10:25 AM, Heiko W.Rupp <hrupp(a)redhat.com> wrote:
On 26 May 2017, at 5:58, Josejulio Martinez Magana wrote:
>> Do we really need to drive off an agent or server-side config? Perhaps
> +1
> I think we should consider this option. The agent provides general
I am not married to the agent providing this metadata, which
is shown by the "or on the server" part ;-)
Driving the UI from metadata on the Hawkular-services
side allows us to add support for new kinds of servers
- outside of MiQ release cycles
- by the people that write those servers without them becoming MiQ experts
Also issues like e.g. a missing property can be fixed on the H-S
side by adding this to the metdata.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
2:47 a.m.
On 27 May 2017, at 0:36, Caina Costa wrote:
So, I went ahead and created a PoC on what I mean could be done on
the
rails side of things on the previous email:
https://github.com/cfcosta/dynamic-entity-poc , and
So how would e.g. a Tomcat server be added here? And
where are the properties of stuff that we already expose
(e.g. server name) and how would the children be linked?
7:08 a.m.
On Jun 20, 2017 04:47, "Heiko Rupp" <hrupp(a)redhat.com> wrote:
On 27 May 2017, at 0:36, Caina Costa wrote:
So, I went ahead and created a PoC on what I mean could be done on
the
rails side of things on the previous email:
https://github.com/cfcosta/dynamic-entity-poc , and
So how would e.g. a Tomcat server be added here?
The structure for that would be defined by the hawkular server, it spits
json to us, and we create the entities based on that.
And
where are the properties of stuff that we already expose
(e.g. server name) and how would the children be linked?
Those would be on the dynamic field as well.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
4:11 p.m.
OK, I can certainly see the advantage of being able to add to or update
our supported entities without requiring changes to MIQ. As Mazz said,
it's a throwback to RHQ where persistence and UI was generically
implemented. The question is whether we can do something similar but
more simple. It's not a small undertaking to convert to a config-driven
UI, especially within the confines of MIQ. My suggestion to have the
UI-config differ from the agent config was motivated by a few things:
* the UI config may need more presentation-only info, I'm not sure
* the UI config wouldn't necessarily need everything in the agent config
* it maintains our current decentralized approach to agent config
On the downside, it would mean keeping another config up to date and
having the server provide it in some way to the gem/ui. It's also not
clear to me MIQ will green-light a generic approach to the db-tables.
When I tried to do some generic things early on it was rejected in favor
of explicit fields and maintaining consistency with the way things were
being done elsewhere. Note that there are hooks with events and alerts,
and maybe metrics, that would likely need to be revisited if we move to
a more generic approach to the tables.
On 5/26/2017 9:25 AM, Heiko W.Rupp wrote:
On 26 May 2017, at 5:58, Josejulio Martinez Magana wrote:
>> Do we really need to drive off an agent or server-side config? Perhaps
> +1
> I think we should consider this option. The agent provides general
I am not married to the agent providing this metadata, which
is shown by the "or on the server" part ;-)
Driving the UI from metadata on the Hawkular-services
side allows us to add support for new kinds of servers
- outside of MiQ release cycles
- by the people that write those servers without them becoming MiQ experts
Also issues like e.g. a missing property can be fixed on the H-S
side by adding this to the metdata.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
11:05 a.m.
Now that Caina is doing a PoC I want to revisit the
source of metadata question again.
On 30 May 2017, at 23:11, Jay Shaughnessy wrote:
changes to MIQ. As Mazz said, it's a throwback to RHQ where
persistence and UI was generically implemented. The
This is to quickly get a 70% version out and to be able to
quickly add new monitored stuff. This should and will not
prevent us from generating more dedicated UI screens later.
* the UI config may need more presentation-only info, I'm not
sure
Yes
* the UI config wouldn't necessarily need everything in the
agent
config
* it maintains our current decentralized approach to agent config
This one I am no longer sure about. It was a great idea
back in the day. I see two cases
* user uses the same config for all WildFlys - why do we
want to duplicate the metadata for all of those if
the (RT) config is effectively the same?
* user has modified the agent config to have
more/less fields. In this case the current MiQ UI would
not adapt to it and in either way just not show the
data. And it may not even be clear when there are
two WildFly in inventory with different configs, why they
don't show this difference
For WildFly in container it may even be less interesting
with the current approach as here all the WildFlys will be
built on one base image (that we supply with a baked in
config?).
5:14 a.m.
see this comment (the last part of it) that mentions a somewhat similar
dynamic concept
http://talk.manageiq.org/t/rethinking-providers-and-managers/2494/11
On Mon, Jun 26, 2017 at 7:05 PM, Heiko Rupp <hrupp(a)redhat.com> wrote:
Now that Caina is doing a PoC I want to revisit the
source of metadata question again.
On 30 May 2017, at 23:11, Jay Shaughnessy wrote:
> changes to MIQ. As Mazz said, it's a throwback to RHQ where
> persistence and UI was generically implemented. The
This is to quickly get a 70% version out and to be able to
quickly add new monitored stuff. This should and will not
prevent us from generating more dedicated UI screens later.
> * the UI config may need more presentation-only info, I'm not sure
Yes
> * the UI config wouldn't necessarily need everything in the agent
> config
> * it maintains our current decentralized approach to agent config
This one I am no longer sure about. It was a great idea
back in the day. I see two cases
* user uses the same config for all WildFlys - why do we
want to duplicate the metadata for all of those if
the (RT) config is effectively the same?
* user has modified the agent config to have
more/less fields. In this case the current MiQ UI would
not adapt to it and in either way just not show the
data. And it may not even be clear when there are
two WildFly in inventory with different configs, why they
don't show this difference
For WildFly in container it may even be less interesting
with the current approach as here all the WildFlys will be
built on one base image (that we supply with a baked in
config?).
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
1:17 p.m.
Heya,
My Proof of Concept for the Dynamic/Generic UI is ready, and can be found
here: github.com/cfcosta/dynamic-entity-poc
There is some documentation on the README.md, but if you guys have any
questions, just ping and I'll add it there.
On Tue, Jul 4, 2017 at 7:14 AM, Alissa Bonas <abonas(a)redhat.com> wrote:
see this comment (the last part of it) that mentions a somewhat
similar
dynamic concept
http://talk.manageiq.org/t/rethinking-providers-and-managers/2494/11
The PoC does exactly that, we just need to define new entities/views for
them.
On Mon, Jun 26, 2017 at 7:05 PM, Heiko Rupp <hrupp(a)redhat.com> wrote:
> Now that Caina is doing a PoC I want to revisit the
> source of metadata question again.
>
> On 30 May 2017, at 23:11, Jay Shaughnessy wrote:
>
> > changes to MIQ. As Mazz said, it's a throwback to RHQ where
> > persistence and UI was generically implemented. The
>
> This is to quickly get a 70% version out and to be able to
> quickly add new monitored stuff. This should and will not
> prevent us from generating more dedicated UI screens later.
>
> > * the UI config may need more presentation-only info, I'm not sure
>
> Yes
>
> > * the UI config wouldn't necessarily need everything in the agent
> > config
> > * it maintains our current decentralized approach to agent config
>
> This one I am no longer sure about. It was a great idea
> back in the day. I see two cases
>
> * user uses the same config for all WildFlys - why do we
> want to duplicate the metadata for all of those if
> the (RT) config is effectively the same?
> * user has modified the agent config to have
> more/less fields. In this case the current MiQ UI would
> not adapt to it and in either way just not show the
> data. And it may not even be clear when there are
> two WildFly in inventory with different configs, why they
> don't show this difference
>
> For WildFly in container it may even be less interesting
> with the current approach as here all the WildFlys will be
> built on one base image (that we supply with a baked in
> config?).
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> 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
2:13 p.m.
Hey,
On 4 Jul 2017, at 20:17, Caina Costa wrote:
My Proof of Concept for the Dynamic/Generic UI is ready, and can be
found here: github.com/cfcosta/dynamic-entity-poc
Awesome - why don't you do a little demo via BlueJeans or
Google Hangouts or such - I think that would be great
for everyone and you could walk us through what you
did so that we can better understand how to evolve it.
Heiko
12:47 a.m.
+1
On Tue, Jul 4, 2017 at 9:13 PM, Heiko Rupp <hrupp(a)redhat.com> wrote:
Hey,
On 4 Jul 2017, at 20:17, Caina Costa wrote:
> My Proof of Concept for the Dynamic/Generic UI is ready, and can be
> found here: github.com/cfcosta/dynamic-entity-poc
Awesome - why don't you do a little demo via BlueJeans or
Google Hangouts or such - I think that would be great
for everyone and you could walk us through what you
did so that we can better understand how to evolve it.
Heiko
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
4:11 a.m.
+1
On Wed, Jul 5, 2017 at 8:47 AM, Thomas Heute <theute(a)redhat.com> wrote:
+1
On Tue, Jul 4, 2017 at 9:13 PM, Heiko Rupp <hrupp(a)redhat.com> wrote:
> Hey,
>
> On 4 Jul 2017, at 20:17, Caina Costa wrote:
>
> > My Proof of Concept for the Dynamic/Generic UI is ready, and can be
> > found here: github.com/cfcosta/dynamic-entity-poc
>
> Awesome - why don't you do a little demo via BlueJeans or
> Google Hangouts or such - I think that would be great
> for everyone and you could walk us through what you
> did so that we can better understand how to evolve it.
>
> Heiko
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> 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
2731
days inactive
2773
days old
21 comments
9 participants
participants (9)
-
Alissa Bonas -
Caina Costa -
Heiko Rupp -
Heiko W.Rupp
-
Jay Shaughnessy -
John Mazzitelli -
Josejulio Martinez Magana -
mike thompson -
Thomas Heute