Enable docker in all the VMs by default

[jstrachan]

It'll be easier to reuse the same vagrant scripts if we make sure we pick an image that has docker installed & dockerd started by default (ideally with common docker images already pulled inside) maybe with locally installed tarballs too of, say, fabric8 distro?

[jstrachan]

I wonder if some kinda snapshot/resume command - like the vbox-snapshot plugin might work
https://github.com/dergachev/vagrant-vbox-snapshot

which would avoid us recreating huge images and instead just running, occasionally, the install script which we could add into the bash: https://github.com/fabric8io/fabric8-devops/blob/master/vagrant/bash/Vagrantfile#L37

[paoloantinori]

I possibly miss some context here but depending on how complete you want the distro I might suggest http://www.projectatomic.io or even https://github.com/boot2docker/boot2docker .

Regarding alternative workflow to build large or slow images, we can consider to:

• have a sequential Dockerfile (instructions added at the end of the file are going to be applied to previously existing layers that you don't have to rebuild)
• interacting with a running instance and taking snapshot of it (you missed the "receipt" though)

[jstrachan]

Yeah, good point; wanna try switch the vagrant files to using projectatomic? :) Not sure where there's a good image we can use in vagrant.

FWIW I recently patched the vagrant file to install docker and pull our main 2 fabric8 images:
https://github.com/fabric8io/fabric8-devops/blob/master/vagrant/bash/Vagrantfile#L50

its actually the pulling of our images thats dog slow ;) installing docker itself is relatively quick in comparison - but I agree we should try switch to projectatomic or something.

It should be easy to make the vagrant file configurable (e.g. via env vars?) so folks can switch between a few different base images based on their requirements really.

FWIW the new ./create.sh and ./reset.sh scripts now take a cleanstate snapshot on creation so we can revert to the snapshot in reset.sh so we can easily revert to a clean state without a slow install

[jstrachan]

@paoloantinori BTW I tried 2 of the images on the projectatomic repo site:

• http://rpm-ostree.cloud.fedoraproject.org/project-atomic/images/f20/vbox/20140607.vdi.bz2
• http://rpm-ostree.cloud.fedoraproject.org/project-atomic/images/f20/vbox/20140609.vdi.bz2

both resulted in:

    integration1: Downloading: http://rpm-ostree.cloud.fedoraproject.org/project-atomic/images/f20/vbox/20140607.vdi.bz2
The box failed to unpackage properly. Please verify that the box
file you're trying to add is not corrupted and try again. The
output from attempting to unpackage (if any):


bzip2: I/O or other error, bailing out.  Possible reason follows.
bzip2: Broken pipe
    Input file = (stdin), output file = (stdout)
bsdtar: Error opening archive: Child process exited with status 1

[jstrachan]

just tried using this image: https://vagrantcloud.com/dduportal/boot2docker but then I got

==> integration1: Setting hostname...
Vagrant attempted to execute the capability 'change_host_name'
on the detect guest OS 'tinycore', but the guest doesn't
support that capability. This capability is required for your
configuration of Vagrant. Please either reconfigure Vagrant to
avoid this capability or fix the issue by creating the capability.
 This machine has the IP '192.168.1.79 and host name 'stracmac.local'
Disabling dockerTaking snapshot cleanstart
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
 This machine has the IP '192.168.1.79 and host name 'stracmac.local'
Disabling dockerTaking snapshot cleanstart
/Applications/Vagrant/embedded/gems/gems/childprocess-0.5.3/lib/childprocess/abstract_process.rb:45:in `initialize': all arguments must be String: ["/usr/bin/VBoxManage", "snapshot", nil, "take", "cleanstart", "--pause"] (ArgumentError)
    from /Applications/Vagrant/embedded/gems/gems/childprocess-0.5.3/lib/childprocess.rb:19:in `new'

[paoloantinori]

Regarding atomic:

• apparently Vagrant support just tar and zip images: https://docs.vagrantup.com/v2/boxes/format.html
  while Atomic uses bz2 if not worse: http://ask.projectatomic.io/en/question/14/why-are-the-qcow2-images-compressed-with-xv-instead-of-bzip2/

I can alter the script to download with wget and extract with from command line, but that would possibly work just for *nix systems. Otherwise I have to find some implementation in pure Ruby, assumed there is one.
I have also commented on the request for a zip archive but I am not feeling lucky.

what do you think @jstrachan ?

[paoloantinori]

Small update: it turned out that Vagrant cannot use directly .vdi files ( I think they represent just a filesystem, not a full VM) so to use the Atomic's one I had to use it in a manually generated VM, that I then exported to a .vbox file with the command vagrant package --base atomic --output atomic.vbox
At that point I was able to use the file in our Vagrantfile.
But I was blocked not being able to connect via ssh, something else to check.

End of the story is: even if we want to use Atomic, it's only a base image. We possibly want to customize it (pre loading the Docker images that we like + whatever else) and we have to publish it to some accessible place.

[paoloantinori]

Making progresses with Atomic. I have now been able to correctly configure the base image to allow remote log in. But I have several failures in Vagrant while performing network configuration. Mainly because of Fedora20 image that uses different conventions and Vagrant apparently does not completely supports it.
Still working on it but let me know if you want my partial work.

.vbox file is 350MB

[jstrachan]

@paoloantinori sounds great!

I wonder if it changes the vagrant file quite a bit if we need to have a separate folder & vagrant file for using different linux distros? Am not sure how easy its gonna be to have a single vagrant file supporting all these different linux distros and approaches etc.

Maybe its just easier if we have a different vagrant file per linux flavour (when they differ greatly) - then over time we can look and see if we can share some ruby code between them; but given they are a page or so long reuse probably isn't that big a deal?

[jstrachan]

BTW I love the idea of defaulting to Project Atomic - especially when doing docker stuff; but at the same time I can imagine lots of customers wanting to stub in their distro of fedora/coreos/ubuntu too and reuse the same vagrant crack to do integration tests

[paoloantinori]

I am actually a newbie in Vagrant world so I cannot make reliable prediction. As you say, having multiple Vagrant file is not that bad. I can actually see that Vagrant developer is interesting in fixing as much as he can.
To give you an idea I am facing here and there problems like these:
hashicorp/vagrant#1997
And with time to do a proper analysis, I'd like to open bugs to them to correctly extend the support.

At the moment, even if it's all so initial, I am already taking the route of custom commands. Instead of using Vagrant native configuration support, I am adding a custom line in the init script.

https://github.com/paoloantinori/fabric8-devops/blob/atomic/vagrant/bash/Vagrantfile

• I have also started experimenting with Packer to produce the base .vbox image that is at the moment a manual process, since we start from a .vdi

[jstrachan]

Sounds cool. I guess another option is to just have a separate, out of band process that builds vagrant compliant image? Vagrant has a docker like registry thing you can use to upload images etc.

[paoloantinori]

Fine for me but I am not sure if Vagrant registry is used only for base O.S. images or for images customized with applications. Because if it's the first case is more something that should be followed by project atomic team to keep up with the new releases.

This in the meanwhile is to keep track of current blockers:

hashicorp/vagrant#2745

[jstrachan]

Agreed. TBH projectatomic should be creating a vagrant compatible image themselves

[paoloantinori]

Mmmm I'm starting to think that Atomic RPM-OSTree is overkill for our needs.

I'm still struggling to understand how to install an .rpm and my understanding is that I have to produce a full rpm tree and store it somewhere on the web to let Atomic pull it and apply it:

http://ask.projectatomic.io/en/question/110/network-broken-in-vagrant/

[jstrachan]

No worries ;) Maybe we just park the ProjectAtomic until there's a vagrant compatible image available?

[jstrachan]

I'm not even sure where to raise an issue for ProjectAtomic to properly support running in Vagrant :)

[rawlingsj]

Kubernetes seems promising...

http://www.projectatomic.io/blog/2014/07/upstream-atomic-vagrant-support-for-kubernetes/

https://github.com/GoogleCloudPlatform/kubernetes#getting-started-with-a-vagrant-cluster-on-your-host