Switch Vagrant VM to something based on TinyCore Linux

[mrdavidlaing]

The current dev VM download, based on Ubuntu 12.04 x64 is ~800MB.

However, if we switched to http://tinycorelinux.net/ linux, we should be able to get this below 100MB.

But, then we'd have a dev environment that isn't the same as the runtime environment.

@david-coombes @sopel - do you think there is any advantage to pursuing this approach further?

[daithi-coombes]

Love the idea of a light box instead of a full blown desktop environment. Puppy linux is another one that has been mentioned repeatedly over the past few years.

As the project is around wordpress development there shouldn't be too much that could cause headaches for dev teams outside of a handful of programs, of the top of my head: libcurl, php and mysql versions. And even still WP_HTTP class handles transport so underlying libcurl versions would only effect apps that are doing non standard networking, where libcurl versions might be effecting headers etc. But lower level differences between the box and the live server such as kernel etc wouldn't effect wordpress.

I wonder would it be overkill to include an 'update-alternatives' script that could switch between the popular versions of the above, similar to java? PHP and MySql would be ok but libcurl needs to be re-installed each time the version changes.

[sopel]

I wasn't aware the Ubuntu in use is the full blown desktop environment? If that would be the case indeed, I'm absolutely in favor of removing the desktop from the default Vagrant setup (providing a readily configured desktop for in VM IDE usage is something I'd like to offer down the road eventually, but it should be strictly an opt-in feature).

However, I do not see the need to optimize the distribution in use to be tiny in fact, after all it is just a one time download once in a while (admittedly I'm commenting from the convenient position of having high bandwidth internet access).

I'm personally not a fan of the proliferation of nix distributions and am already uncomfortable with Ubuntu in this regard, insofar I'd rather see the underlying Debian GNU/Linux to deliver the long term stable standard distribution for server OS usage - unfortunately Debian has failed to address the significantly different needs within cloud computing early on and Ubuntu has done a really great job in this space, which is why it is still the EC2 go to OS for nix use cases as far as I know (likely followed by the CentOS based ones including the Amazon Linux AMI) - this might change now with Debian GNU/Linux finally providing some kind of official AMIs for EC2 usage, but I wouldn't hold my breath.

Anyway, I'm mentioning this because my (utterly personal) experience so far has been that using anything but the widely supported OS on EC2 immediately called for trouble in a lot of subtle ways, so I'd be afraid that maintaining a consistent requirements setup for EC2 and Vagrant will be more work than it is going to be in the first place already.

But, then we'd have a dev environment that isn't the same as the runtime environment.

That's exactly the point, the DevOps perspective within X. Dev/prod parity stresses to keep development and production as similar as possible, which is a widely shared lesson learned from real world experiences with this issue - using a different OS/Distribution wouldn't be a good starting point for this ;)

[daithi-coombes]

Agreed it does break the X. Dev/prod parity but I feel only on a comaprison of the full environments and not on comparison of the actual development environment . Only advantage I see in using the tiny box would be specifically for the wordpress community, in which case the tools that are use by the team, lamp (lhmp), would still allow to keep development and production as similar as possible and might arguably stay within the boundary's of the dev/prod parity. Purely from the pressupbox point of view I think the tiny box might make sense, and even increase its use across the community, but from a boilerplate pov on other deployments outside of wordpress it might not.

[sopel]

@daithi-coombes - you are making a very good point differentiating the use case resp. target audience; in fact I was about to comment that I consider myself to be a low priority stakeholder in this particular incarnation of the remote development boilerplate project, insofar I'm not involved with anything WordPress outside of our Labs Team environment (and even there I'm basically just a user). So please disregard my preferences as you see fit :)

[daithi-coombes]

... also that might cause problems if we do go down this route is the mailer. List of variables that would have to match live server stands at:

• php
• mysql
• mailer
• libcurl

The mailer might be the blocker here. WP_Mail class handles emails but the underlying daemons on the vm will set headers, logs etc.

[daithi-coombes]

lol, commenting at the same time, yours came first

your comments are always welcome, to the point and very well put. Comment freely ;)

[mrdavidlaing]

Having slept on it; I'm in agreement with @sopel that keeping dev/prod parity is more important; so I'm going to stop working on this for the moment.

One minor point; our dev VM is NOT the desktop install of Ubuntu 12.04, rather its based on the server version of Ubuntu 12.04 "shipped" with Vagrant - http://files.vagrantup.com/precise64.box; and with our dependancies installed, and then "pruned" as much as possible as per: http://dominique.broeglin.fr/2011/03/26/squeeze-64-vagrant-base-box.html. Thus, as Ubuntu 12.04 server installs go, its pretty lean already (I think). At least, when I did a minimal debian "netinstall" I got a larger VM size.

That being said, I agree with @daithi-coombes that WordPress has few enough dependancies to possibly be a special case that a different base distro could work. Further, in our specific use case, since we use HipHop rather than Apache2/php, and buildpack bundles the hiphop and its dependancies into your app during deployment, only only actual external dependancy is the linux kernel version & mysql.

Perhaps we can revisit this at a later date.