Mount and use host's go binary in the vagrant vm

[mapuri]

This allows to relax the strict version check for host go version.

Fixes issue #30

[jainvipin]

@mapuri - if go version is picked up from host:

• how does someone run the test when native Vagrant on a laptop? i.e. will it pick up the default go version in the Vagrant VM?
• the main problem was lib compatibility, the code doesn't seem to be recompiling libs inside the VM in case of a mismatch. I am trying to understand if this will work with incompatible go versions (the packages compiled in in the VM vs. go version provided by the host)? Did you try mismatching versions i.e. with 1.4.2 go version to ensure these changes work?

[mapuri]

@jainvipin

how does someone run the test when native Vagrant on a laptop? i.e. will it pick up the default go version in the Vagrant VM?

With this change the 'go' installed in vagrant vm shall never be used. Even on a laptop setup, assuming the user brings up the 'vagrant vm' using 'make demo' then it will correctly pass the path of go-binary on the laptop to the vm for mounting and using it.

the main problem was lib compatibility, the code doesn't seem to be recompiling libs inside the VM in case of a mismatch. I am trying to understand if this will work with incompatible go versions (the packages compiled in in the VM vs. go version provided by the host)? Did you try mismatching versions i.e. with 1.4.2 go version to ensure these changes work?

Yes, I think the problem still exists. Just tried mismatching versions and didn't work. I think the go version installed on the vm is still interfering even though it is using host's go binary 😞 . Will continue digging.

[mapuri]

I think I found the issue, looks like just mounting the go-binary directory is not enough, we need to mount the host's go-root as well. After mounting the go-root I am able to run tests with a mismatch in go environment. I have updated the PR with the change.

Just as a side note, we can get rid of the go installation in the vagrant-vm completely to easily debug any related issues, but it will need updating the vagrant box. I shall track that as part of separate PR.

[jainvipin]

@mapuri - looks good; one more follow-up. This would lock out the laptop users completely, now that there is no go binary to pick up from the host. i.e. entire dev environment is not within the VM anymore? Or, is it still available?

[mapuri]

@jainvipin

This would lock out the laptop users completely, now that there is no go binary to pick up from the host. i.e. entire dev environment is not within the VM anymore?

I am not sure if I understand the usecase. The current change only affects the vagrant based setups. Without a workspace checkout on the laptop, the users are not able to do a 'vagrant up'. If they do checkout a workspace on their laptop, I would think they have go installed in their host (laptop) environment as well. Is that correct?

In case users have their own VMs on the laptop, they will need to install go on the vms themselves. This should be similar to today as well.

There is a third way (though rare I would think), where user checkouts the netplugin workspace on their laptop (without go), and use 'vagrant up' to manually bring up a vm. I think it will fail today because it tries to mount the GOPATH from host and will some changes to vagrantfile to just bring up the vm without mounting the workspace etc but in that case it just become like another vm and will fall back to the last case f user bringing up their own vm.

Or, is it still available?

Having said above, the vagrant-box that we use still has the go binary etc, just that I have plugged it out of the PATH, so it is not available by default.

[jainvipin]

I should have make it clearer. Is following true?

• Now laptop users will have to make a go-binary before launching the test runs
• They didn't have to do that before (source code was still required)

If yes, then we have made it difficult for laptop users to run more now.

[mapuri]

let's talk about it. I think you are asking about the last case I was pointing to. In that case all they are getting is a regular vm (by using the workspace to do 'vagrant up'), why won't they just have their own vm where they checkout the source and build? Also in this environment then they can at best test/run a single node with netplugin, etcd, ovs running on this vm itself.

Even today I don't think they can build the netplugin binary in the vagrant vm as is because the GOPATH from host is mounted as read-only.