Check for patchlevels when running scripts/checks#29
Conversation
There was a problem hiding this comment.
Right now there is a tight coupling of go-version between host and vagrant environment (where we run unit-tests and it has go1.4) due to go-objects being incompatible between different versions of go. As a result we kept this check strict.
A detailed description of the dependency can be found in this PR as well #17 . It's a trade off we made between keeping test running time low and go-development environment at that moment.
|
Sounds good @mapuri, I'll close this. Regarding my other question re: testing in docker -- is that something we can do or is a host VM necessary? Additionally, it seems like I have to be able to build this on the host and the VM. I'm on a mac, so vishvananda/netlink doesn't build in the first step. Is there a way around this? Sorry to ask questions here, I know this is probably not the best spot, but I have no better way to chat atm. |
|
Netplugin itself could run as docker container. However the entire setup (one/two host) needs a VM because it expects an independent OVS instance on each node/host. The best way to get it to work on a MAC is to spawn two VMs using Vagrant, launch netplugin and fire up json config. We need to update the docs with those instructions. |
Yes, this came up recently in some other discussion as well. I think it might be doable but there are certain things that will need to be looked at and I haven't gotten a chance to explore. Right now we use the vagrant vm(s) to provide a way to simulate multi-host environment (by deploying a vm per host). Each vm is just a ubuntu machine with etcd and ovs running. And in multi-host setups we connect the vms using virtualbox bridge for a bare bone Layer2 pass thru. With a docker based sandbox, I think running etcd is certainly doable in the container but I am not very sure about running ovs though (as it depends on the kernel for datapath). ovs does provides a userspace datapath, but I am not very familiar with it, so that might need some investigation. For multi-host simulation, I think we should be able to use default docker bridge (the way we use virtual-box bridge)
I am not sure. @jainvipin would you know? |
|
ah ok; making sense now. Sorry for the ignorance. I'll see what I can do about automating things in a way that's more mac-friendly tonight. It'll get me more familiar with the code. |

This makes it so that go 1.4.2 can run this project.
Still getting familiar and working out bootstrapping the build env here. Would it make sense to test this under docker itself?