host only networking as per boot2docker PR 198

[SvenDowideit]

It works, creates a new network when needed, or reuses one if the cfg is the same as the one specified.

We need something to get the IP address out of the VM.

• using a scripted ssh isn't very portable - expect on windows?
• perhaps just add a fingerd to boot2docker that just spits out some status?
• or ... is this information available via the docker API?

[SvenDowideit]

@steeve @tianon @riobard @aheissenberger what do you think?

[steeve]

What about UPNP or MDNS? Seriously

[riobard]

Do you want the actual IP of the VM before it's running? I thought it's dynamically assigned, so you have to wait until the VM is booted.

[steeve]

I'm really thinking mDNS (Zeroconf/Bonjour) is the way to go.

Because:

• its use case is specifically this: machine discovery
• nss-mdns is already in the TCL repo (we can choose to start it only if on VMs)
• there are pure-go mDNS implementation (both provider and consumer)

Also, for shared folders, we will need guest->host mounting: that means the VM will need the host IP too (maybe we already have it if the host is the DHCP?).

[SvenDowideit]

@steeve thankyou - last month I was thinking mDNS, this month its totally slipped my mind.

I'm still hoping that we can implement shared folders the other way round - using data-containers that are shared using nfs/samba/whatever - and this PR lays the groundwork (ie, automates what I did by hand :) ) Then again, BEAM might just totally do away with the need for the host dir portion.

[riobard]

Oops, seems you are talking about a different use case :)

@SvenDowideit People on OS X/Windows would still need a way to share files from the host OS to the VM. How does the data container approach solves that problem? I was trying to build a dev box using containers before but the file sharing is problematic on OS X which made that plan unattractive :(

I don't know what is BEAM, do you mean this repo https://github.com/dotcloud/beam?

[SvenDowideit]

riobard, no not really, What I'm proposing, is that rather than have boot2docker mount your User dir - and steal all your data and send it to someone so they can hack your bank account, that you mount a data volume on your OSX box, and then work from there.

There are a couple of benefits - the files are local to the docker daemon, so that can be faster - meaning you can share a docker vm with other people, and not have network issues, security - which is kind of important, and it means we leverage some core docker best practices right from the get-go.

So the work flow is - create a data-container, attach an nfs/smb/?? server container to that data-volume, and then mount it from the OSX/Windows box.

if you can show me a use case where inverting the solution can't work, please keep throwing them at me until we come to a working solution :)

[riobard]

@SvenDowideit Thanks for the clarification! Now I see how it's supposed to work. Yes, I agree this is a more secure solution.

I think SMB2 would be ideal, as it is supported natively on both OS X (10.9+) and Windows (7+ I think?), and it is supposed to have good performance (compared to SMB) especially with lots of small files.

[riobard]

I was watching @bradfitz talking about Camlistore at FOSDEM '14 today. From there I found a pure Go implementation of a FUSE filesystem (http://bazil.org), so another option is maybe Docker can expose a filesystem that OS X users can mount using OS X FUSE?

[SvenDowideit]

mmm, bazil's not got windows support yet :/

[riobard]

Yeah, that's right. Windows doesn't support FUSE either…

[SvenDowideit]

@steeve @riobard @tianon @aheissenberger

can we merge this, then I'll work on adding mDNS (client side) to detect the hostonly ip address, (and maybe even DOCKER_HOST and SSH settings?) that the boot2docker OS (or the docker daemon itself) broadcasts.

[riobard]

SGTM!

[tianon]

Are you sure these are the correct env vars the code is actually checking for?

[riobard]

The README is really outdated now :)

Should we get rid of env vars all together and rely on flags + profile for config (i.e. the Docker approach)? Somehow I feel env vars won't scale as we add more options down the road.

[tianon]

+1

[riobard]

Ok, I'll rewrite the config code tomorrow. I'll create a PR once it's in good shape.

[SvenDowideit]

excellent. I really detest ENV vars - they cause all sorts of pain supporting users that forgot, or didn't realise that there was one sitting in their .profile

[steeve]

LGTM :)

[SvenDowideit]

@riobard can we merge this before you change the config code to use flags?

[riobard]

@SvenDowideit Sure! I'll fix the config and README then.