Apologies for the delay in replying to this -- I've been travelling. Replies inline where they belong.
On Wed, Sep 15, 2010 at 12:33:37PM +0100, Soren Hansen wrote: > I have a spec[1] and a corresponding branch[2] about making basic use of > libvirt's nwfilter support. It basically just adds a snippet to the > libvirt templates that enables a number of network filtering techniques. > Specifically, it prevents MAC spoofing, ARP spoofing, and IP spoofing. I > didn't bother making this configurable, since it seems like the sort of > thing everyone will always want. As such, there's no API call to enable > it, nor is there a setting in the datamodel that enables/disables it. > > While this is a great feature to have, it raises a few questions about > the non-libvirt hypervisors. > > Ideally, of course, we don't want the choice of hypervisors to affect > the utility of Nova. Lacking decent network filtering IMO limits a cloud > computing platform's utility significantly. > > So, what to do? Should we more clearly define the contract to which a > hypervisor driver is meant to adhere and list the above mentioned > spoofing protections as requirements? I think in the future we have to be willing to accept that some features are optional at the hypervisor layer. When I add the "play the Blue Danube Waltz through the PC speaker" feature that I've been working on, I don't expect all other platforms to support it. Particularly since that would mean getting it into the underlying platforms _and_ libvirt. For most things though, we're likely to want them to be supported by all platforms equally. Anti-spoofing is definitely one of those. I would certainly support a common profile for hypervisors, saying what they need to be able to to in order to be OpenStack-ready. This feature is definitely one of those. Note that XenServer (the commercial product) can't actually do this network filtering today. Netfilter is compiled out of our commercial kernel, and we don't yet support the use of Open vSwitch, which would be the alternative implementation. We will be addressing this with haste, as we recognise the necessity of this in any public cloud environment. Users of Xen Cloud Platform (the OSS software) can of course compile a kernel with netfilter support, so we will be able to test this particular feature through XenAPI using XCP. > We could assign specific people as > designated maintainers of the different hypervisor drivers, and make it > their responsibility to make their driver conformant to the contract. I'm happy for Citrix to take that role for the XenAPI driver. I assume that you wouldn't want to block a merge on the grounds that it extended the hypervisor contract without the necessary changes to all the drivers. That would end up as a big bottleneck waiting for everyone to implement their piece. I wouldn't want to block merges like that. However, it's probably reasonable that we would want to co-ordinate well enough that the support was lined up for each release milestone. That means that someone who wants to extend the hypervisor contract would need to check that there was enough manpower available from each of the designated maintainers in order to get the work completed before the next release. Either that, or the feature has to be optional. How does that sound? Ewan. _______________________________________________ Mailing list: https://launchpad.net/~nova Post to : [email protected] Unsubscribe : https://launchpad.net/~nova More help : https://help.launchpad.net/ListHelp
