Open jstrachan opened 10 years ago
jstrachan
commented
10 years ago 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
commented
10 years ago 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:
jstrachan
commented
10 years ago 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
commented
10 years ago @paoloantinori BTW I tried 2 of the images on the projectatomic repo site:
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 1just 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'Regarding atomic:
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
commented
10 years ago 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
commented
10 years ago 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
commented
10 years ago @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
commented
10 years ago 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
commented
10 years ago 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: https://github.com/mitchellh/vagrant/issues/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
.vbox image that is at the moment a manual process, since we start from a .vdijstrachan
commented
10 years ago 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
commented
10 years ago 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:
jstrachan
commented
10 years ago Agreed. TBH projectatomic should be creating a vagrant compatible image themselves
paoloantinori
commented
10 years ago 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
commented
10 years ago No worries ;) Maybe we just park the ProjectAtomic until there's a vagrant compatible image available?
jstrachan
commented
10 years ago I'm not even sure where to raise an issue for ProjectAtomic to properly support running in Vagrant :)
rawlingsj
commented
10 years ago
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?