Sorry for the delay responding. I wanted to read through the proposed review which was updated overnight.
I think the current direction of the code is starting to head in the right direction, but I don't think it goes far enough. I was thinking about the problem on my run today and realized that part of the issue might be the blueprint description. The blueprint summary and title say to convert to RPC, but in reality all that is needed is a combination of notifications (which are already emitted by Quantum) and targeted API calls. Adding RPC actually increases the complexity and number of changes and essentially duplicates notification functionality. At DreamHost, we we built our own L3 router service based off Quantum's notifications and http api. Using both, we were able to keep the existing agent/server relationship and improve the communication efficiency by only making requests when needed. Another benefit to this design was that we were able to keep the number of files changed to a minimum: one (l3_agent.py). mark PS: I'm working get that code open sourced, so folks can take a look. On Nov 13, 2012, at 7:54 AM, Gary Kotton <[email protected]> wrote: > Hi, > I too have added some comments to the document. > Thanks > Gary > > > On 11/13/2012 12:06 PM, Salvatore Orlando wrote: >> >> Hi Yong, >> >> I added some more comments on the google document. >> I don't think this design is bad. Still, I believe we can smooth some >> details in order to keep the efficiency improvement that you are achieving >> with a lesser impact on the plugin. >> >> I also have some more comments inline. >> >> Thanks, >> Salvatore >> >> On 12 November 2012 23:50, gong yong sheng <[email protected]> >> wrote: >> Hi salv-orlando and markmcclain, >> >> There is no email back for a long time since I sent out the spec, So I had >> not paid attention to the spec for a while. >> >> I do apologise for that. However, as you know, when this happens it's not >> because we're deliberately ignoring the work. >> >> I have replied mark's comments. >> >> I have to say, this design is of high efficiency. >> >> I agree that the goal will be to increase efficiency of the interface >> between the plugin and the agent. >> >> 1. l3 agent does not bug server many times within a sync cycle. >> >> Agreed, but I suspect we'll be paying an undesired price in terms of >> scalability of the server side component. >> I have some comments on the google document and a suggestion for an >> alternative, which I'm pretty sure you've already considered. So it's up to >> you telling me why the alternative would be worse than the solution you're >> proposing :) >> >> 2. We use adjustable periodical time to sync data so that even if >> administrator operates routers' data in a frequent manner, >> the system's behaviour can be expected. There is no notification and data >> exchange between l3 agent and quantum server for every >> router operation. This will create latency between router update and putting >> into operation. Of course, we can modify the algorithm so that >> l3 agent will sync data after each router and its related data modified. ( >> including created, deleted, updated) >> >> I found interesting that you are seeing periodic sync as a better approach >> compared to notifications. I agree the period of synchronization is >> tuneable, and expert deployers will be able to analyse their traffic pattern >> and find the optimal sync period. Still, notifications is a widely and >> successfully used mechanism in a wide set of apps. So I'm curious to hear >> why you think they might not be as good as periodic syn in our case. >> >> interface >> >> the interface between quantum server and l3 agent is simple: >> l3 agent -> quantum server: >> sync_routers(host, synctype) >> synctype is full sync and incremental sync. >> first time is full sync and then we will use incremental sync for normal >> operations. >> If sync >> quantum server -> l3 agent >> router_deleted(router_id) >> >> Are you explicitly using notifications for delete events in order to avoid >> the need for soft deletes? >> From what I gather the sync mechanism is not able to cope with object >> deletions. >> Soft deletes are actually my biggest concern. Is this the only kind of >> notification you're looking at? >> >> Data structure on server side: >> >> mapper for l3 agents' sync object: >> >> quantum server keeps a mapper for sync objects of agents: >> sync object is just keeping last sync time >> >> to deal with quantum server restart: >> quantum server will start full sync for coming sync to re build the cache. >> >> I don't understand this bit. Will the quantum server a notification to all >> agents inviting them to do a full sync? >> >> to deal with l3 agent restarts: >> l3 agent will use full sync to replace the sync object on the server side. >> >> This is pretty much clear. >> >> big router concept >> >> on server side, we have a concept of a big router: include router, its >> gateway port, its interfaces and related floating ips. >> >> one sync will sync all of these data by one shot from server to l3 agent. >> >> with multi-host and multi-l3 agents coming, we will be able to distribute >> the big routers among l3 agents. so don't worry about the data size in one >> sync. >> >> Indeed. But why worry about maintaining the last sync state for a lot of >> agents? I know your answer would be that it's just a data structure which >> maps an agent id to a timestamp, and it's a good argument. But we'll also >> have increased state because of the added fields, and increased computation >> logic as you'll need to scan all objects for veryfing whether more have been >> created/updated since last sync, and the number of those object can grow >> quite a lot. >> >> >> patches are: >> >> Add created_at and updated_at datetime columns. I think adding created_at >> and updated_at are agreed by many core members, even if we don't agree the >> sync way. >> l3 agent rpc. (WORKINPROGRESS) It is sync algorithm by now. >> >> Thanks >> Yong Sheng Gong >> >> >> >> -- >> Mailing list: https://launchpad.net/~quantum-core >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~quantum-core >> More help : https://help.launchpad.net/ListHelp >> >> >> >> > > -- > Mailing list: https://launchpad.net/~quantum-core > Post to : [email protected] > Unsubscribe : https://launchpad.net/~quantum-core > More help : https://help.launchpad.net/ListHelp
-- Mailing list: https://launchpad.net/~quantum-core Post to : [email protected] Unsubscribe : https://launchpad.net/~quantum-core More help : https://help.launchpad.net/ListHelp
