Jeremy Davis's picture

In essence I agree with you ("a build is a build is a build"). Although because of the intention of Vagrant (i.e. the problem it is trying to solve) it doesn't have some (important IMO) features baked in (like backup, etc). Although, using Vagrant with TKL might be a winner for people using TKL products day to day (developing/managing servers/websites for customers, etc.). For example if you have specific plugins that you use everytime, rather than building them into the TKL appliance, adding them with a Vagrant script might be more useful (and quicker and easier - especially considering that ATM TKLDev only outputs ISOs).

Something else that Vagrant doesn't do is produce real machines. From what I've read it's great at provisioning virtual machines and as you said, now even includes support for AWS. But what about other hosting platforms? What about people that want to run TKL on bare metal hardware? Going down an exclusive Vagrant path would remove the TKL relevance for those users... And a solution that loses TKL users (if ISO builds and alternate cloud provider support are lost) or increases maintenance overheads (by needing to create a Vagrant build and an ISO/build for alternate hosting providers) is probably not a great idea...

Thinking about this more though... Now TKL supports LXC (as a host and as a container) and there is a Vagrant plugin for LXC perhaps that would be a development option?

Also in some respects Docker is trying to solve similar issues to Vagrant, although in quite a different way. With Docker support perhaps that is another direction for TKL to take? In my travels I found quite an interesting article on Docker vs Vagrant. At the end it talks about integrating the usage of Docker and Vagrant... So perhaps there is a place for Vagrant, even if TKL goes the Docker route? FWIW there is also a Vagrant Docker provider!

[off topic] Also you prompted me to update TurnKey's Ohloh profile. I added a heap more repos so it looks a bit healthier now! :)