11:07 a.m.
Thanks for the detailed explanation!! really helpful
2021년 12월 6일 (월) 오후 4:50, Piotr Kliczewski <pkliczew(a)redhat.xn--com>-4f21ay07k 작성:
>
>
>
> On Mon, Dec 6, 2021 at 6:24 AM Henry lol <pub.virtualization(a)gmail.com> wrote:
>>
>> 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)
>
>
> During the transition process we had several protocols being supported so the
abstractions are
> there. Raw tcp is there and you can implement "just" json-rpc on top of it.
In the past we were using xmlrpc
> so with this approach you would have unidirectional communication and no
notifications.
> It was our starting point with the transport changes we did.
>
>>
>>
>> but as Artur said, the main reason for using stomp here seems to
>> easily propagate and define msg flows, right?
>
>
> There is more to it. We use stomp heartbeats to determine if a host is healthy. It is
used to trigger fencing flow when the host is not reachable.
>
>>
>>
>> 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.
>>