[openstack-dev] [Nova] Things to tackle in Liberty
Neil Jerram
Neil.Jerram at metaswitch.com
Fri Apr 10 15:48:58 UTC 2015
On 10/04/15 04:34, Kevin Benton wrote:
> IIRC there was some work to make the plugging call out to a script so
> all of the calls to various vswitches don't need to be in Nova. I would
> prefer this to removing all plugging logic from Nova.
Yes, indeed. I had https://review.openstack.org/162468 (WIP: VIF plug
script support for Nova) in my mind already, but
https://review.openstack.org/#/q/owner:%22Brent+Eagles%22,n,z reveals
lots more detailed work by Brent Eagles in this area.
> The main reason I would be hesitant to leave plugging completely out of
> Nova is that it requires an agent on the compute node, which isn't the
> case right now (e.g. plugins based on openflow, ovsdb, or something
> similar with a remote controller handling the setup of forwarding logic).
Understood, that it's nice to be able to do without an agent.
What I imagine, though, is that the _source_ of the plugging information
could move from Nova to Neutron, so that future plugging-related code
changes are a matter for Neutron rather than for Nova. The plugging
would still _happen_ from within Nova, as directed by that information.
(For libvirt, I believe the required information would be the interface
type and parameters to go into the libvirt XML, and then any further
processing to do after that XML has been launched. I believe the latter
is covered by the vif-plug-script spec, but not the former.)
However, on thinking this through, I see that this really is bound up
with the wider question of nova-net / Neutron migration - because it
obviously can't make sense for plugging information to come from Neutron
if some people are not using Neutron at all for their networking.
Stepping right back, though, is it agreed in principle that detailed
networking code should move from Nova to Neutron, if that is possible
while preserving all existing behaviours? If it is agreed, that's
something that I'd like to help with.
Thanks,
Neil
More information about the OpenStack-dev
mailing list