On Mon, May 21, 2012 at 10:20 AM, Gary Kotton <gkot...@redhat.com> wrote:
> ** > Hi, > Thanks for the comments. Please see my replies inline. I hope that these > will not take up too much CPU on your side. > Thanks > Gary > > > On 05/21/2012 07:57 PM, Dan Wendlandt wrote: > > Btw, this actually isn't the case for the OVS plugin. The OVS vif > driver in Nova passes the entire attachment UUID to OVS by setting an > attribute on the local OVSDB entry for that port (note: the ovsdb is a > simple embedded database that runs as part of OVS on the hypervisor... it > is completely distinct from the primary database used by the OVS plugin). > > Can you please point me out to the code in Nova. I want to make sure that > I have my bases covered. > There are two version of the OVS + libvirt vif-driver... one for libvirt 0.9.10 and earlier (no built-in support for OVS) and below that, one for libvir 0.9.11 +. For the older version of OVS + libvirt you can see here that we grab the vif UUID, and then specify it as the 'iface-id' attribute in OVS external-ids for port: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py#L124 For the newer version, we pass the vif-uuid in directly as a parameter to libvirt, which in turn communicates it to OVS: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py#L187 > > > > In addition to this I think that there are a number of additional issues >> that we need to address: >> 1. Inclusion of openstack common - on the IRC last night it was mentioned >> to have a blueprint for the config (I feel this only addresses a small part >> of the problem). I think that we should do this for the openstack common >> project. Thgis will be healthier in the short and long run. >> > > I think the proposal was to use the existing config library that is > already a part of openstack common. Is that what you are suggesting, or > something else? > > Yes, this is correct. As far as I understand the Open Stack common library > may not support 2.4. It may have to be updated. > > >> 2. Python 2.4. I have yet to understand how to identify which modules >> are from later versions. If this is a MUST for the agents then we can leave >> the agents as they are and introduce new agents that support RPC. Is this a >> viable solution? >> > > I'd REALLY like to avoid having the core team work on two separate > versions the agents for 2.4 vs. > 2.4. I think it would slow us down. For > 2.4 things that are purely syntactic (e.g., not using "as" for exceptions), > I think its fine for us to enforce this as part of our code review process. > If there are libraries important to new capabilities where the clearly > superior choice is not an option for 2.4, I think we need to raise this as > a community discussion point. Is there a particular module you have in > mind? > > I am not familiar with Xen. I am trying to understand why the agents have > to run in dom0. From my understand the VIF driver does not run in dom0. > Would it be possible to understand why the driver has to run in dom0? > Right now, agents run commands to manipulate bridges locally. It could be rewritten so that the agent runs in a service VM along with nova-compute and then communicates OVS changes to dom0 via another channel. We just have to weigh the complexity of implementing, maintaining and documenting a separate choice over the cost of keeping agents 2.4 compatible. > > I am not sure if you have read > https://docs.google.com/document/d/1MbcBA2Os4b98ybdgAw2qe_68R1NG6KMh8zdZKgOlpvg/edit. > I have the linuxbridge up and running. This make use of a hacked library of > the RPC - hopefully in the near future we will be able to import the common > library. Once the linux bridge library is up and running I'll proceed to > make the changes to the OVS. > Just looking at it now. I'd really caution against having generic calls like "device_added", since the set of things that may need to be fetched when a device appears will likely increase significantly in the future, even if Folsom-2 (things like security groups, QoS settings, etc.). I'd rather have specific calls that have a well-defined schema that we think will be reasonably stable over time. In Nova we've had very bad experiences with RPCs that just pass large dictionaries of data around, where the "schema" of that dictionary grows organically over time is and is not really documented anywhere. Also, at least for the OVS plugin, I'd like to avoid using the device name as the key that is sent back. The OVS agent already knows the attachment-id, so there's no need to pollute the code with the device name. Thanks, Dan > > Thanks > Gary > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
