Hi,
Sorry for not being able to attend the IRC meeting - it was in the
middle of the night :)
Whilst I was working on the integration of Quantum into oVirt I
encountered a number of issues and challenges regarding the agents. Some
of the issues were discussed in yesterdays meeting namely:
1. High availability
2. Scalability
*High Availability*
I discovered that when the agent was unable to access the database it
would terminate on a exception. This has been addressed partially by
https://review.openstack.org/#/c/6744/ (thanks to Maru Newby for the
comments - updated, tested manullay for linuxbridge and ovs). I saw that
Maru opened a bug regarding agent unit tests (kudos). I have tested the
ovs agent and the linux bridge agent manually.
I have yet to update the RYU agent (Isaku Yamahata suggested that we
speak about this at the meeting). I think that we need to address this
across the board and not only in the agents, but also in the plugins.
The database access should be done via a common class that takes the
connectivity into account. I do not feel that this is part of the bug
fix above it is more of a system wide fix.
*Scalability*
This is a recurring topic. I understand that from the summit the idea of
using AMQP came up. This still requires a "PUSH" from the plugin to the
specific agent. After dealing with the agents above I wonder if we
actually need the agents? Let me try and elaborate: when a VM is
deployed the VIF plugin (I think that that is the terminology) creates
the tap device, sets it to up and in the case of OVS notifies the
integration bridge of the tap device. In the background the agent is
running. When the agent discovers that the tap device exists and it
matches a attachment from the database it "plugs" the device in and
updates the database with the port status.
Why not have the VIF plugin also do the interface plugin? This can and
may solve a large number of scalability issues mentioned. This will be
moving part of the logic from the agent to the VIF plugin.
It would be intersting to know the rationale of the current implementation.
Thanks
Gary
--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp
