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]
<mailto:[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
<https://launchpad.net/%7Equantum-core>
Post to : [email protected]
<mailto:[email protected]>
Unsubscribe : https://launchpad.net/~quantum-core
<https://launchpad.net/%7Equantum-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
