On 25 May 2017, at 3:43, John Mazzitelli wrote:
This is the infamous "sync" problem. We have been
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
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
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.