8:12 a.m.
Can you explain to me what's the big picture of the command
gateway? What's
the chain of calls when, for instance, there's a new deployment in Wildfly?
Joel asked this question - I figured it is good to post to h-dev, too, since I'm sure
others don't know this.
The "big picture" is:
First, remember the MiQ UI is connected to Hawkular-Services server via websocket. The
agents all connect to some Hawkular-Services server via a websocket. There can be more
than one Hawkular-Services server running and the UI may be talking to a server that is
different than the server the agent is talking to:
UI <---websocket---> Server A
^
|
(message bus)
|
V
Server B <---websocket---> agent
1) MiQ sends a JSON message over the websocket to a Hawkular-Services server (Server A in
the diagram above).
2) Hawkular-Services server A looks at the ResourcePath in the message to determine what
agent is responsible for managing that resource.
3) Hawkular-Services server A addresses the message to the proper agent and puts the JSON
message on the agent's queue on the message bus.
3b) At this point the Hawkular-Services server A sends back a JSON message to the UI over
the websocket that says "message forwarded to the bus".
4) The Hawkular-Services server that has a websocket connection to the targeted agent
picks off that message from the bus (Server B in the diagram)
5) That Hawkular-Services server B forwards the message to the agent via its websocket
connection.
6) Agent looks the the message's ResourcePath and the rest of the JSON to determine
what it needs to do. It does the action.
// now the process goes in reverse
7) Agent sends back a response to the server B over websocket (either a success or fail
message)
8) Server B takes response, figures out which UI the response should go to, and puts it on
message bus addressed to the correct UI
9) The Server A takes the response message off the bus
10) Server A sends the response message to the UI over its websocket connection.
Tell me if I'm correct, for what I've seen it's MIQ
which, though the ruby
client, sends a websocket event, caught by the WF agent through the command
gateway. In the end, the WF agent will perform a full sync of affected root
resources in inventory. Is that correct?
In the case of a "Deployment" JSON message, yes, the agent will trigger a full
discovery scan so it can quickly discover the new deployment you just added to WildFly.
If that's correct, there's no direct interaction between
inventory and the
command gateway. I'm asking because I hope we can keep the command gateway
messages unchanged, and change only places where there's direct calls to
the inventory rest api.
Most of the time, its just using ResourcePath API (just that simple inventory POJO).
HOWEVER, I believe Jay added some code that does interact with Inventory to do things like
create relationships in inventory when new cluster entities are added. That is why (I
think) he did this commit. Though I can't remember where this code is that builds
inventory relationships - he'll have to point that out. But I'm pretty sure there
is some inventory stuff going on under the covers for that stuff - more than just using
the canonical ResourcePath stuff.
8:26 a.m.
New subject: Command gateway and WF agent
Nice explanation, thanks!
On Tue, Mar 7, 2017 at 3:12 PM, John Mazzitelli <mazz(a)redhat.com> wrote:
> Can you explain to me what's the big picture of the command
gateway?
What's
> the chain of calls when, for instance, there's a new deployment in
Wildfly?
Joel asked this question - I figured it is good to post to h-dev, too,
since I'm sure others don't know this.
The "big picture" is:
First, remember the MiQ UI is connected to Hawkular-Services server via
websocket. The agents all connect to some Hawkular-Services server via a
websocket. There can be more than one Hawkular-Services server running and
the UI may be talking to a server that is different than the server the
agent is talking to:
UI <---websocket---> Server A
^
|
(message bus)
|
V
Server B <---websocket---> agent
1) MiQ sends a JSON message over the websocket to a Hawkular-Services
server (Server A in the diagram above).
2) Hawkular-Services server A looks at the ResourcePath in the message to
determine what agent is responsible for managing that resource.
3) Hawkular-Services server A addresses the message to the proper agent
and puts the JSON message on the agent's queue on the message bus.
3b) At this point the Hawkular-Services server A sends back a JSON message
to the UI over the websocket that says "message forwarded to the bus".
4) The Hawkular-Services server that has a websocket connection to the
targeted agent picks off that message from the bus (Server B in the diagram)
5) That Hawkular-Services server B forwards the message to the agent via
its websocket connection.
6) Agent looks the the message's ResourcePath and the rest of the JSON to
determine what it needs to do. It does the action.
// now the process goes in reverse
7) Agent sends back a response to the server B over websocket (either a
success or fail message)
8) Server B takes response, figures out which UI the response should go
to, and puts it on message bus addressed to the correct UI
9) The Server A takes the response message off the bus
10) Server A sends the response message to the UI over its websocket
connection.
> Tell me if I'm correct, for what I've seen it's MIQ which, though the
ruby
> client, sends a websocket event, caught by the WF agent through the
command
> gateway. In the end, the WF agent will perform a full sync of affected
root
> resources in inventory. Is that correct?
In the case of a "Deployment" JSON message, yes, the agent will trigger a
full discovery scan so it can quickly discover the new deployment you just
added to WildFly.
> If that's correct, there's no direct interaction between inventory and
the
> command gateway. I'm asking because I hope we can keep the command
gateway
> messages unchanged, and change only places where there's direct calls to
> the inventory rest api.
Most of the time, its just using ResourcePath API (just that simple
inventory POJO). HOWEVER, I believe Jay added some code that does interact
with Inventory to do things like create relationships in inventory when new
cluster entities are added. That is why (I think) he did this commit.
Though I can't remember where this code is that builds inventory
relationships - he'll have to point that out. But I'm pretty sure there is
some inventory stuff going on under the covers for that stuff - more than
just using the canonical ResourcePath stuff.
9:49 a.m.
New subject: Command gateway and WF agent
First, remember the MiQ UI is connected to Hawkular-Services server
via websocket.
One small nit, the MIQ UI websocket connection is via our ruby gem, so
really any user of the rubly client could, I think, utilize the cmdgw stuff.
... HOWEVER, I believe Jay added some code that does interact with
Inventory to do things like create relationships in inventory when new
cluster entities are added.
There is no code in cmdgw doing any interaction with inventory. In
cmdgw we only declare the supported request/responses. There are two
aspects of hServices that interact with inventory.
The InventoryEventListener listens for JMS events publish by Inventory
and is responsible for:
* generating Added/Removed Server events to be consumed by MIQ
o using events for various server types
* generating "isClusteredWith" relationships for clustered servers
o using events for JGroups Channels
Inventory will no longer be generating these events and this listener
will likely have to go away. Either the agent will need to start
generating the events or we'll need a new component to drive off of the
persisted inventory data in metrics.
The Feed BackFill mechanism:
* Needs to get and set the avail metrics for a feed's resources when
the feed goes down (detected either by lack of avail heartbeat, or
via broken websocket).
We will need to replace the inventory traversal query with something
based on the new metrics impl.
On 3/7/2017 9:26 AM, Joel Takvorian wrote:
Nice explanation, thanks!
On Tue, Mar 7, 2017 at 3:12 PM, John Mazzitelli <mazz(a)redhat.com
<mailto:mazz@redhat.com>> wrote:
> Can you explain to me what's the big picture of the command gateway?
What's
> the chain of calls when, for instance, there's a new deployment
in Wildfly?
Joel asked this question - I figured it is good to post to h-dev,
too, since I'm sure others don't know this.
The "big picture" is:
First, remember the MiQ UI is connected to Hawkular-Services
server via websocket. The agents all connect to some
Hawkular-Services server via a websocket. There can be more than
one Hawkular-Services server running and the UI may be talking to
a server that is different than the server the agent is talking to:
UI <---websocket---> Server A
^
|
(message bus)
|
V
Server B <---websocket---> agent
1) MiQ sends a JSON message over the websocket to a
Hawkular-Services server (Server A in the diagram above).
2) Hawkular-Services server A looks at the ResourcePath in the
message to determine what agent is responsible for managing that
resource.
3) Hawkular-Services server A addresses the message to the proper
agent and puts the JSON message on the agent's queue on the
message bus.
3b) At this point the Hawkular-Services server A sends back a JSON
message to the UI over the websocket that says "message forwarded
to the bus".
4) The Hawkular-Services server that has a websocket connection to
the targeted agent picks off that message from the bus (Server B
in the diagram)
5) That Hawkular-Services server B forwards the message to the
agent via its websocket connection.
6) Agent looks the the message's ResourcePath and the rest of the
JSON to determine what it needs to do. It does the action.
// now the process goes in reverse
7) Agent sends back a response to the server B over websocket
(either a success or fail message)
8) Server B takes response, figures out which UI the response
should go to, and puts it on message bus addressed to the correct UI
9) The Server A takes the response message off the bus
10) Server A sends the response message to the UI over its
websocket connection.
> Tell me if I'm correct, for what I've seen it's MIQ which,
though the ruby
> client, sends a websocket event, caught by the WF agent through
the command
> gateway. In the end, the WF agent will perform a full sync of
affected root
> resources in inventory. Is that correct?
In the case of a "Deployment" JSON message, yes, the agent will
trigger a full discovery scan so it can quickly discover the new
deployment you just added to WildFly.
> If that's correct, there's no direct interaction between
inventory and the
> command gateway. I'm asking because I hope we can keep the
command gateway
> messages unchanged, and change only places where there's direct
calls to
> the inventory rest api.
Most of the time, its just using ResourcePath API (just that
simple inventory POJO). HOWEVER, I believe Jay added some code
that does interact with Inventory to do things like create
relationships in inventory when new cluster entities are added.
That is why (I think) he did this commit. Though I can't remember
where this code is that builds inventory relationships - he'll
have to point that out. But I'm pretty sure there is some
inventory stuff going on under the covers for that stuff - more
than just using the canonical ResourcePath stuff.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
2824
days inactive
2825
days old
2 comments
3 participants
participants (3)
-
Jay Shaughnessy -
Joel Takvorian -
John Mazzitelli