[ovirt-users] Re: Questions about VDSM communication protocol
2021년 12월 3일 (금) 오후 7:39, Piotr Kliczewski <pkliczew(a)redhat.xn--com>-4f21ay07k 작성:
On Fri, Dec 3, 2021 at 11:22 AM Henry lol <pub.virtualization(a)gmail.com> wrote:
>
> In my understanding, an internal broker was introduced with benefits and enough to
cover the workload, right?
In general it is correct. There is no broker process running but rather the code is
spread between the client (engine) and server (vdsm).
>
>
> but not clear about the need for it on oVirt because I'm not sure there are so
many message flows(or message topics).
We created a topic per type of interactions (commands) that are being called. Good number
of them are defined.
>
> I felt like it acts as just a proxy only between engine and rpc server, so it looks
more desirable to me to directly communicate without message queues in the middle.
> (even internal broker is coupled with vdsm)
We were concerned about topology complexity and never decided to use an external (proxy)
broker. The transport communication hides details so from a logic perspective it
looks like direct communication. Please remember that in the past transport was fully
synchronous and one of the requirements was to abstract async so the business layer
can work without changes.
yeah as you said, the business layer can focus on their own logic
thanks to the transport layer.
I thought that the transport layer could be also abstracted and
implemented from raw tcp or websocket, and at first that using msg
protocol with the broker is just an additional overhead. (correct me
if i'm wrong)
(i.e. json-rpc communication through tcp or websocket)
but as Artur said, the main reason for using stomp here seems to
easily propagate and define msg flows, right?
sorry again in advance if it sounds foolish.
>>
>>
>> could I know usecases of it in oVirt compared to raw tcp?
>
>
> Interesting one is bidirectional notifications which need to be delivered to specific
parts of the logic on either side.
> For most of use cases we could get away with raw tcp.
>
>>
>>
>> sorry in advance if it sounds foolish.