Thanks for the detailed explanation!! really helpful
2021년 12월 6일 (월) 오후 4:50, Piotr Kliczewski <pklic...@redhat.com>님이 작성: > > > > On Mon, Dec 6, 2021 at 6:24 AM Henry lol <pub.virtualizat...@gmail.com> wrote: >> >> 2021년 12월 3일 (금) 오후 7:39, Piotr Kliczewski <pklic...@redhat.com>님이 작성: >> > >> > >> > >> > On Fri, Dec 3, 2021 at 11:22 AM Henry lol <pub.virtualizat...@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. >> _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/XDXRPOS3PCYE2H363ALNDHMSP66IYWC5/
