[Hawkular-dev] Command gateway and WF agent

Joel Takvorian jtakvori at redhat.com
Tue Mar 7 09:26:30 EST 2017


Nice explanation, thanks!

On Tue, Mar 7, 2017 at 3:12 PM, John Mazzitelli <mazz at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170307/75e4eb91/attachment-0001.html 


More information about the hawkular-dev mailing list