On 05/06/2019 02:49, Yi Yang (杨燚)-云服务集团 wrote: > Robert, thank you so much for your insightful answers, I'm wondering if we > can have a meeting to discuss this specially, last week, we discussed this in > openflowplugin weekly meeting, I believe you participated in ODL DDF and > joined discussion about :ODL scale" Luis presented, it will be great let us > have a meeting to focus on this.
Well, I believe in rough consensus and running code -- and I have not seen anything aside from high-level slides so far. > Abhijit, Anil, does my suggestion make sense? Robert is the strongest arguer > for akka-based ODL cluster. I am not arguing either way. What I am doing here is dispelling misconceptions and trying to understand the *exact* nature of the problem. > Robert, but in ODL cluster, there is only one leader node no matter how many > nodes we have, I think it is bottleneck, isn't it? That is not correct. Every Shard has its own leader and it is a matter of how shards are laid out. > In my mind, message queue is the only feasible way to synchronize data in > larger scale distributed application, I'm not sure if akka is using the same > way to handle data synchronization. I would like to get your idea about this. > I know akka uses gossip, but leader node will be responsible for > synchronizing data to all the other follower nodes, this is a big issue, in > message queue solution, message servers can handle this workload, data > producer just send data once, in current ODL cluster, I think, the leader > node will send N-1 times data to all the other follower nodes, please correct > me if I'm wrong. I do not see how a message queue (directly) is solving the problem. At the end of the day, every actor has a message queue, so what are we really talking about? This thread has been heavy on CDS criticism, without ever mentioning what the applications are doing, how or why. Before jumping to solutions, I *really* would like us understanding the requirements and the problem we are faced with -- software engineering is *engineering*, i.e. picking reasonable trade-offs from the solution space for a given problem space and constraints. Currently, there has been no data floated in this thread, so ... can we follow UNPHAT, as per https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb ? Regards, Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openflowplugin-dev mailing list openflowplugin-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
