Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check for patchlevels when running scripts/checks #29

Closed
wants to merge 1 commit into from
Closed

Check for patchlevels when running scripts/checks #29

wants to merge 1 commit into from

Conversation

erikh
Copy link
Contributor

@erikh erikh commented Mar 17, 2015

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?

@jainvipin
Copy link

@erikh - we should fix this, but this change alone may not cut it unless Sanity Vagrant VM is also updated to pick up the updated go version. @aanm also tried out similiar change in another PR (still open). In fact few of us have run into this.
The reason to do this was to ensure that build speeds are faster. Comments @mapuri ?

@@ -5,7 +5,7 @@
echo "Checking Go version..."
ver=$(go version | awk '{print $3}')
expVer="go1.4"
if [[ ${ver} != ${expVer} ]]; then
if ! echo "$ver" | grep -qE "^$expVer"; then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@erikh
Copy link
Contributor Author

erikh commented Mar 17, 2015

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.

@erikh erikh closed this Mar 17, 2015
@jainvipin
Copy link

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.

@mapuri
Copy link
Contributor

mapuri commented Mar 17, 2015

Would it make sense to test this under docker itself?

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)

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?

I am not sure. @jainvipin would you know?

@erikh
Copy link
Contributor Author

erikh commented Mar 17, 2015

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.

@jainvipin
Copy link

thanks @erikh - if anything can make it going easily for laptop users, would be a wonderful contribution.

Regarding netlink compilation - yes you'd have to compile this in a VM, natively on MAC is something I haven't tried out.

dseevr pushed a commit to dseevr-dev/netplugin that referenced this pull request Nov 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants