Bug 1363728

For now moving to ovirt_future, we need to discuss and prioritize 4.x plans around communication improvements

(In reply to Martin Perina from comment #1)
> For now moving to ovirt_future, we need to discuss and prioritize 4.x plans
> around communication improvements

Can you discuss and prioritize now?

This rfe is very good idea but it would make backward compatibility harder between the versions. In the original design we went with the approach we have today due to the bugs that we found in activemq (we wanted to use it as messaging backbone). There are changes required in the engine which would make us to rethink the flows we have and how to handle subscriptions per verb.

In the original design we wanted to move towards events where we have no subscription limitations so I propose to add some of the events that MOM needs without making bigger redesigns.

Where is the backwards compatibility issue?

- 4.2 VDSM already has the code that allows it to listen for the sub-topics and we can disable that for 4.1 hosts
- The reply topic name is always sent as a header so vdsm does not need to think about it at all, it will just use whatever came in with the request

Are there any other places where the topic names are important?

(In reply to Martin Sivák from comment #4)
> Where is the backwards compatibility issue?
> 
> - 4.2 VDSM already has the code that allows it to listen for the sub-topics
> and we can disable that for 4.1 hosts

When we install vdsm first we subscribe to specific queue and later we query vdsm for version information. How should we subscribe to get the response for specific
queue. At this stage we do not know whether vdsm contains [1] patch or not.

> - The reply topic name is always sent as a header so vdsm does not need to
> think about it at all, it will just use whatever came in with the request

When we receive SEND frame we need to know whether to call API.py or just deliver
it to specific queue.

> 
> Are there any other places where the topic names are important?

> When we install vdsm first we subscribe to specific queue and later we query
> vdsm for version information. How should we subscribe to get the response
> for specific
> queue. At this stage we do not know whether vdsm contains [1] patch or not.

Why not subscribe to both then?


> When we receive SEND frame we need to know whether to call API.py or just
> deliver
> it to specific queue.

That is already handled by the vdsm side. It delivers everything that starts with the known topic root to API.py. You can send the initial message to the root to figure out what version of vdsm you are talking to.

VDSM in 4.2 actually does not care about subtopics. But other components (mom, hosted engine) can subscribe to only some of them and that avoids the overhead  of parsing and dropping all the non-important ones.

Actually, you do not have to subscribe to both, you can just use the root topic for the Reply-To header during the initial exchange. Basically treating the host as a 4.1 host before you detect newer version. 4.2 VDSM still allows that (it is used like that right now).

I am not saying it is not possible to do it but there is a bit of code to be written to handle all the compatibility changes.

I see much clearer solution using events. It would be least invasive approach to provide information for MOM.

MOM (and hosted engine) would have to listen to everything and filter out a huge amount of frames (because of VM status and migrations) or invent a whole new topic and VDSM would have to start sending events to that MOM specific topic. That is not how topics are used..

Hardly less invasive than just using the current method to get the host version (we can even do that based on the cluster compatibility level) and enabling the topic suffixes only for 4.2 and higher.

I am proposing adding new queues/topics for specific event types which could be consumed by anyone who is interested in receiving those. There would be no need for filtering.

Please note that we would need to detect vdsm version and act accordingly. New 4.2 vdsms would need to work with older versions of engines as well.

(In reply to Piotr Kliczewski from comment #10)
> I am proposing adding new queues/topics for specific event types which could
> be consumed by anyone who is interested in receiving those. There would be
> no need for filtering.

I am not talking about events (how many do we have? 2?). I am talking about RPC commands that are all sent to a single topic.

> Please note that we would need to detect vdsm version and act accordingly.
> New 4.2 vdsms would need to work with older versions of engines as well.

But they do already! VDSM does not care about the suffix and it just uses whatever you set to the Reply-To header. This is already done, merged and working. No additional code change is needed.

(In reply to Martin Sivák from comment #11)
> (In reply to Piotr Kliczewski from comment #10)
> > I am proposing adding new queues/topics for specific event types which could
> > be consumed by anyone who is interested in receiving those. There would be
> > no need for filtering.
> 
> I am not talking about events (how many do we have? 2?). I am talking about
> RPC commands that are all sent to a single topic.
>

I see this as improvement if we would add new events.
 
> > Please note that we would need to detect vdsm version and act accordingly.
> > New 4.2 vdsms would need to work with older versions of engines as well.
> 
> But they do already! VDSM does not care about the suffix and it just uses
> whatever you set to the Reply-To header. This is already done, merged and
> working. No additional code change is needed.

This implies that specific commands/verbs are aware of subscriptions which is bad idea.

We are not going to implement this. As described above it's possible to achieve similar result by adding more events, which don't cause any compatibility issues or requiring deep infrastructural changes