| Thread Previous • Date Previous • Date Next • Thread Next |
On 07/19/2012 07:11 PM, Dan Wendlandt wrote:
On Wed, Jul 18, 2012 at 5:17 AM, Gary Kotton <gkotton@xxxxxxxxxx <mailto:gkotton@xxxxxxxxxx>> wrote:On 07/18/2012 04:23 AM, Dan Wendlandt wrote:Hi Gary,Removing much of the thread history, as I think we agree on the high-level goals. Now just focusing on the differences.For example, a DHCP agent handling all DHCP for a deployment might register for create/update/delete operations on subnets + ports, whereas a plugin agent might only register for updates from the ports that it sees locally on the hypervisor. Conceptually, you could think of there being a 'topic' per port in this case, though we may need to implement it differently in practice.The agent ID is currently stored in the database (this is for the configuration sync mechanism). I think that adding an extra column indicating the capabilities enables the service to notify the agents. The issue is how refined can the updates be - we want to ensure that we have a scalable architecture.I think either we can implement the filtering ourselves using a mechanism like this, or we can rely on the message bus to do it for us. I'm not really familiar with the scalability of various message bus implementations, but a simple model would be that there's a topic for:- port creation - net creation - subnet creation
This is an interesting idea. In addition to the creation we will also need the update. I would prefer that the agents would have one topic - that is for all updates. When an agent connects to the plugin it will register the type of operations that are supported on the specific agent. The agent operations can be specific as bit masks.
I have implemented something similar in https://review.openstack.org/#/c/9591
This can certainly be improved and optimized. What are your thoughts?In addition to this we have a number of issues where the plugin does not expose the information via the standard API's - for example the VLAN tag (this is being addressed via extensions in the provider networks feature)
There are a number of things that we need to address:1. Support for different plugins - if acceptable then the model above needs to be more generic and a common interface should be defined. 2. Support for different agents. This is pretty simple - for example the DHCP agent. It has to do the following: i. use the health check mechanism (this registers the mask for the notification updates) ii. add in support for port creation (I guess that I can add this as part of this patch) 3. Logging. At the moment the agents do not have a decent logging mechanism. This makes debugging the RPC code terribly difficult. This was scheduled for F-3. I'll be happy to add this if there are no objections. 4. We need to discuss the notifications that Yong added and how these two methods can interact together. More specifically I think that we need to address the configuration files.
The RPC code requires that the eventlet monkey patch be set. This cause havoc when I was using the events from pyudev for new device creation. At the moment I have moved the event driven support to polling (if anyone who reads this is familiar with the issue or has an idea on how to address it any help will be great)
and a specific topic for each entity after its created to learn about updates and deletes.
I prefer having a cast to a specific topic than a broadcast all. (please look at https://review.openstack.org/#/c/9591/3/quantum/plugins/linuxbridge/lb_quantum_plugin.py - method update_port - line 174).
as I said, we may need to implement this logic ourselves is using many such topics would not be scalable, but this seems like the kind of think a message bus should be good at..In general, I think it is ideal if these external agents can use standard mechanisms and formats as much as possible. For example, after learning that port X was created, the DHCP agent can actually use a standard webservice GET to learn about the configuration of the port (or if people feel that such information should be included in the notification itself, this notification data uses the same format as the webservice API).I am not sure that I agree here. If the service is notifying the agent then why not have the information being passed in the message (IP + mac etc.) There is no need for the GET operation.My general bias here is that if there are now two ways to fetch every type of information (one via the standard "public" interface and another via the "internal" interface with a different implementation) that is twice the testing, updating, documenting that we have to do. Perhaps the two problems we're trying to solve are sufficiently different that they require two different mechanisms, but in my use cases I haven't seen that yet.
This is a tough one. On one hand I agree with you. On the other I think that we should have a better tuned and optimized system. Yes, this may require a bit more effort but I think that it is more robust. Another issue is that each plugin has its own traits and characteristics. Private additional data may have to be transferred.
Thanks Gary
Dan ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: www.nicira.com <http://www.nicira.com> twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Thread Previous • Date Previous • Date Next • Thread Next |
