Hi Yong, thanks for updating the specification. I am unfortunately unable to look at it and the associated patch set now. I will do that in my afternoon.
Thanks, Salvatore On 14 November 2012 03:15, gong yong sheng <[email protected]>wrote: > Hi Garyk, Salvatore, Mark and Dan, > > Thanks for the spec reviews, > I have modified the spec and > https://review.openstack.org/#/c/15619/4 is there in consistency with the > spec. > > I think the main concerns are: > 1. created_at and updated_at fields. > 2. cache on server > The new design and implementation does not have these two stuff. > 3. for router distribution among multiple l3 agents, we will do it in > quantum scheduler and multiple hosts and agents features. > In scheduler, we will enable agents to report their state to quantum > server, then quantum server can schedule routers, dhcp stuff to related > agents. > > Thanks > Yong Sheng Gong > > > On 11/14/2012 09:18 AM, Dan Wendlandt wrote: > > Yes, realistically, the blueprint should have said "avoid expensive > polling when using l3-agent". During Folsom, the way we did this for the > L2-agents was introducing an RPC-layer, so that is what we named this > blueprint, but in hindsight that is specifying the mechanism, not the goal. > > Dan > > On Tue, Nov 13, 2012 at 2:28 PM, Mark McClain > <[email protected]>wrote: > >> 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.<https://review.openstack.org/#/c/15476/>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) <https://review.openstack.org/#/c/15619/>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 >> >> > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dan Wendlandt > Nicira, Inc: www.nicira.com > twitter: danwendlandt > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > -- > 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
