Implement proxying box calls on the IPROTO level

[akudiyar]

Summary:
Allow users to interact with vshard or Cartridge cluster as with a single Tarantool instance. This may be achieved via proxying the box.* calls on the iproto level.

Description:
There are a number of connectors that are designed to work with a single Tarantool instance, some of them are even unmaintainable. Also exposing cluster management details to users may be unnecessary if they want only reliable storage.

In this case, a proxy for IPROTO_* calls can solve the problem. Since these calls over iproto can not be proxied on the Lua level, changes must be done on the iproto implementation level.

[kostja]

There is already a ticket for this - implement proxy module

…

On Fri, May 22, 2020, 12:45 Alexey Kuzin ***@***.***> wrote: Summary: Allow users to interact with vshard or Cartridge cluster as with a single Tarantool instance. This may be achieved via proxying the box.* calls on the iproto level. Description: There are a number of connectors that are designed to work with a single Tarantool instance, some of them are even unmaintainable. Also exposing cluster management details to users may be unnecessary if they want only reliable storage. In this case, a proxy for direct box.* calls can solve the problem. Since these calls over iproto can not be proxied on the Lua level, changes must be done on the iproto implementation level. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5012>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADV4XQ7ECAP3SRQIR3TIJTRSZCUPANCNFSM4NHUQS6Q> .

[olegrok]

There is already a ticket for this - implement proxy module

#2625

[akudiyar]

@kostja You probably mentioned the ticket #2625 -- although it looks similar, the main case and goal are different. Solving of this issue may lead to solving the other somehow.

[kostja]

Well, how would you implement vshard proxying without failover? vshard router currently fails over automatically. #2625 is a subset of this issue, not a different issue.

[Mons]

No, these tikets are completely different.
This ticket i about API: access to IPROTO_SELECT, IPROTO_UPDATE, IPROTO_INSERT, so on...
That ticket is about to implement something on top of... maybe this ticket.

I hardly vote for this ticket. And for implementation of proxy I will use github.com/moonlibs/apex

[kostja]

I have no idea what "access API" you're talking about.
Ggiven that you guys think is different and I don't is a good sign this is all messed up. I suggest to use an existing ticket and write a better description for it, maybe splitting the work into independent parts. Otherwise it's a mess - the bugs database is a collection of badly described issues which are only understood by their authors.
Speaking of the nature, no it is not different, before you can bounce iproto commands to the right shard, you need to be able to bounce it to the right replica, as vshard is currently doing both.

[Mons]

I've tired to swordplay with you.
You didn't even try to understand what we are talking about and what the problem we are try to solve.
You're completely blaming any newly created tickets, always referring your own but very old tickets, even if they only a bit relative.
What was the force, that stopped you from implementing all of those tickets, when you was the head of core development team?

[akudiyar]

@kostja @Mons Guys, please, stop flaming. Let this ticket be discussed and then all the necessary merges and new tickets will be done.

[sharonovd]

tarantool/vshard#150

This ticket is slightly more related