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

[Andy Zhou]

On Thu, Jan 15, 2015 at 10:22 PM, Motonori Shindo <motonori at shin.do> wrote:
>
> 2015-01-16 5:26 GMT+09:00 Andy Zhou <azhou at nicira.com>:
>>
>> On Thu, Jan 15, 2015 at 9:58 AM, Thomas Graf <tgraf at noironetworks.com>
>> wrote:
>> >
>> > We might need to move the providers into the individual vm definitions
>> > when we start adding more distributions. Due to the outer is executed
>> > first rule that was fixed earlier.
>> Make sense.  I will make the change.
>
>
> I used to be opposed to using config.vm.define block as it was simply a
> single machine setup, not a multi-machine setup. Another reason I was
> against it was when it is extended to a multi-flavor environment (as a
> matter of fact, I am working on it right now) it would look like
>
>  config.vm.define "fedora" do |fedora|
>       fedora.vm.box = "chef/fedora-20"
>  end
>
>  config.vm.define "ubuntu" do |ubuntu|
>       ubuntu.vm.box = "chef/ubuntu-13.10"
>  end
>
> which will bring up both Fedora and Ubuntu VM at the same time. This is
> probably not an indented behavior in most cases.
>
> That being said, I just found that there is a way to control which machine
> to bring up in Vagrantfile by passing an argument to "vagrant up" command
> (e.g. "vagrant up fedora" or "vagrant up ubuntu") and even specify the
> default machine to bring up in case when no argument is passed to "vagrant
> up". For example,
>
>  config.vm.define "fedora", primary: true do |fedora|
>       fedora.vm.box = "chef/fedora-20"
>  end
>
>  config.vm.define "ubuntu" do |ubuntu|
>       ubuntu.vm.box = "chef/ubuntu-13.10"
>  end
>
>  then "vagrant up" will bring up just Fedora VM.
>
> This also allows us to set up more heterogeneous environment like Fedora and
> Ubuntu VM simultaneously if really desired.
>
> Now I really like this multi-machine idea. I will pursue this direction and
> post a patch soon.

This is in-line with my understanding. Some provisions are not
distribution specific and
may be reused.
>
> BTW, do you really think we should run all these provisioning commands as
> "root"? I personally prefer to execute it with "privileged: false" by
> default and sudo for only commands that requires root privilege. Will you
> give me more rationale behind your proposed change?

I stared by running the commands are non-root user. But quickly ran
into permission
issues and path issues -- They all can be solved, but given that we
want to test the kernel modules
that need root access most of the time, it does not seem simple to
write makefile and tests and can deal with
both mixed users.  For example, running tests depends on all program
to be built. If we launch the test
but finding dependencies not satisfied, should we drop back to normal
user to build? In case test writes into
a directory as a root users, normal build process may not be able to
"clean" them.

Over all the trade off is that one can launch VM as a normal user, run
the test within the VM as root. If
we think of VM boxes are disposable, this may be a good balance
between simplicity and usability.

On the other hand, I don't oppose to run commands as regular users if
three is no complexity trade-offs.
>
> Regards,
>
> ---
> Motonori Shindo
>