[openstack-dev] [neutron] Testing Neutron with latest OVS
Tony Breeds
tony at bakeyournoodle.com
Thu Jan 14 04:51:38 UTC 2016
On Wed, Jan 13, 2016 at 10:47:21PM +0000, Sean M. Collins wrote:
> On Wed, Jan 13, 2016 at 03:57:37PM CST, Mooney, Sean K wrote:
> > One of the ideas that I have been thinking about over the last month or two is do we
> > Want to create a dedicated library file in devstack to support compilation and installation
> > Of ovs.
>
> So, my suggestion is as follows: create a new devstack plugin that is
> *specifically* geared towards just compiling OVS and installing it to
> get the bits that you need. I'm just concerned about the feature creep
> that is happening in the Neutron DevStack plugin ( which I didn't like in
> the first place ) where now every little thing is getting proposed
> against it.
>
> I'd prefer to see small, very specific DevStack plugins that have narrow
> focus, and jobs that need them for specific things adding them to their
> local.conf settings explicitly via enable_repo lines.
>
> The concern I have with compiling bleeding edge OVS and then running our
> Neutron jobs is that yes, we get new features, but yes we also get
> the newest bugs and the configuration matrix for Neutron now gets a new
> dimension of 'packaged OVS versus git commit SHA'
For nova we're working on a devstack plugin that will add a repo config to the
host and then upgrade a set of packages from that repo. The idea being to
decouple the compile step from the job.
basically:
echo deb http://host/path main > /etc/apt/sources.list.d/bleeding_edge.list
apt-get udpate
apt-get install $package_list
but you know with error handling etc. I'm sure it can be abstracted to handle
multiple repos and package lists if you're interested?
The devstack plugin could be taught to installed from a per-compiled tgz rather
than a deb/rpm if you wanted but really packages aren't that hard.
The challenge for you guys is the kernel side of things but if I understood
correctly you can get the kenrel module from the ovs source tree and just
compile it against the stock ubuntu kernel (assuming the kernel devel headers
are available) is that right?
Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160114/d01026f4/attachment.pgp>
More information about the OpenStack-dev
mailing list