[ovs-dev] [PATCH 3/3] Vagrantfile: add test_ovs_kmod provision

Thomas Graf tgraf at noironetworks.com
Fri Jan 16 11:47:58 UTC 2015


Just noticed that somehow we had openvswitch.com in the CC list ;-)
Moving back to list.

On 01/16/15 at 11:31am, Dave Tucker wrote:
> 
> On 16 Jan 2015, at 10:40, Thomas Graf wrote:
> 
> >On 01/16/15 at 09:42am, Dave Tucker wrote:
> >>The packer definitions for the "chef" boxes are here
> >>https://github.com/opscode/bento
> >>
> >>It's possible to host the defintions in a git repo, have Jenkins handle
> >>builds, upload the boxes to Amazon S3  and update the boxes in Atlas
> >>(formerly Vagrant Cloud).
> >>A possible downside is that Atlas is going to be a "paid" service so
> >>some
> >>funding might be necessary in future to host these boxes.
> >>Of course, if they are on S3, you can just point the config.vm.box_url
> >>there...
> >
> >Seems like you have quite some experience here. From my limited
> >experience so far we seem to test against the following boxes:
> >- Distro boxes with set of well known distro kernels
> >- Some default distro box with set of stable kernels and
> >net/net-next.
> >
> >For the distro tests we should be able to reuse existing boxes and
> >just provision the right kernel package onto them before running
> >check-kmod and check-kernel. My 1 minute search to do this came up
> >with vagrant-reload:
> >
> >https://github.com/exratione/vagrant-provision-reboot
> >
> >So we could take default chef boxes and just up/downgrade kernels.
> 
> That is, IMO, the best approach.
> Plugins are a whole world of pain though as there is no way to specify the
> dependency in the Vagrantfile.
> The least worst option is README + Error out when plugin is not installed.
> 
> >The upstream stable kernels probably require individual boxes built
> >with packer. As for net and net-next we would need a special
> >bootstrap which compiles and installs kernel. I have something I use
> >locally for net-next that we might be able to reuse but I'd need to
> >clean it up a bit. Is there any advantage of having the boxes on S3
> >rather than Atlas or vice versa?
> 
> With Atlas your config.vm.box is simply "ovs/ubuntu-14.10", you also get box
> versioning (which is cool) and your box is searchable on Atlas.
> Your Atlas box can still be hosted on S3... you just need to use the API or
> the Web Interface to tell Atlas about it
> 
> With plain old S3 you'd have config.vm.box = "ovs/ubuntu-14.10", and
> config.vm.box_url = "<url goes here>".
> 
> And you can s/S3/$any_other_content_hosting_service/g in both cases.
> 
> 
> >>An alternative would be to do something like this:
> >>
> >>https://gist.github.com/4e371d8fd860a4987cee
> >>
> >
> >I absolutely love this. An obvious further multi-distro extension
> >would be:
> >
> >distros = [
> > {name=>"fedora", bootstrap=>$bootstrap_fedora},
> > [...]
> >];
> >
> >for distros.times do |d|
> > for kernels.times do |k|
> >     [...]
> > end
> >end
> 
> Exactly! :)



More information about the dev mailing list