This is incorrect. I am not trying to reimplement libvirt at all. If anything, I'm providing the infrastructure to use libvirt WITH Vagrant. Actually, surprise! I'm working with RedHat to do JUST THIS.
I applaud the libvirt project for everything they've done. We've had our difference, but I have no intention of competing with that project. The power in Vagrant is the workflow of Vagrant, not Vagrant's ability to abstract away the hypervisor (and I certainly don't want to play that game).
The power in Vagrant is the workflow, and that is the game that I'm playing.
Everytime I try to like libvirt, I start reading the documentation and want to claw my eyes out when I remember just how complicated it makes things.
libvirt might be ok if you really need to try to be independent of virtualization technology (though from the looks of it, doing so still requires you to limit yourself to a small subset of functionality) and have really complicated needs, but for a lot of use cases it is ludicrous amounts of overkill.
libvirt is (internally) complicated because it really does a huge amount of work for you [the vagrant developers will no doubt discover this over time].
The API isn't so complex, since there are only perhaps 10 calls that you need to know, plus some XML, and it's all documented in extreme detail. If anything I'd say the problem with libvirt is the documentation is too detailed, and there still aren't any good starter API tutorials.
It's the usage, not the internals, I find overcomplicated.
Every time I've looked at it, I've just ended up writing a small shell script to do what I needed instead rather than having to deal with the convoluted XML config and read through massive amounts of documentation.
If you're writing or editing XML, then you're probably doing it wrong (which to be fair could be a problem with the documentation). You should probably be using commands like:
virsh start MyGuest
To create guests: virt-install, virt-manager, Boxes, Heat, OpenStack or one of the many other libvirt users. None require XML editing.
In any case, that's not an issue for the topic here. The Vagrant developers will certainly need to read up some libvirt API documentation, but once they have made the sensible decision to use libvirt, then that will be completely hidden inside Vagrant, and wouldn't affect end users of Vagrant in any way.
I added a libvirt backend to libguestfs (previously we were managing KVM processes by hand). The change is completely transparent to libguestfs users.
> To create guests: virt-install, virt-manager, Boxes, Heat, OpenStack or one of the many other libvirt users. None require XML editing.
All of which adds more complexity to do something I can do trivially without libvirt.
I might just not be the right target for it, given that I have the luxury of being able to use only LXC and OpenVz, and in both cases creating and managing VM's with the tools provided is extremely easy.
> In any case, that's not an issue for the topic here. The Vagrant developers will certainly need to read up some libvirt API documentation, but once they have made the sensible decision to use libvirt, then that will be completely hidden inside Vagrant, and wouldn't affect end users of Vagrant in any way.
Of course as someone using mostly LXC and OpenVz, to me Vagrant also seems totally over-engineered for what it does. It's at least a factor of 10 larger than what we use to build and deploy our entire production clusters. I'm very happy I don't have to deal with that kind of complexity just to get some dev environments set up.
They are right now in the stages of removing proprietary code towards a modular architecture. I think it's more likely they could implement libvert as a plugin. The focus isn't to make a pluggable architecture for vm emulators(libvert). But to make vagrant itself more robust, by removing it's ties to virtualbox with a plugin system.
I've always liked what vagrant did for the other systems (re: non-linux). However, with this change, it seems they are indeed going in this direction and, well, that is a shame. I might be missing something but it seems they would do much better to build on other tech.
The best I've seen is Ubuntu and how it does it (using libvirt among others, KVM etc - http://www.ubuntu.com/business/server/virtualisation). Would be awesome if they were all playing well together. And, perhaps, vagrant is going to actually do that in the future.
Ubuntu's business server is hardly something as turn-key as vagrant.
We use Ubuntu on EC2 and Canonical has made so many atrocious decisions since the release of 10.04, I am not sure if I ever want to run anything from them again. =( We are however heavily invested with custom PPAs and all that.
Back to Vagrant - as others said before: `vagrant up` and productivity starts. At work I manage local and remote people and they all work with Vagrant. It works the same for developers and frontend people. And most importantly: it works.
Yes, there are ins and outs, but they are mostly Virtualbox related and I cannot wait until other virtualization is supported.
Everywhere I look with Ubuntu they are making the right decision, so I'm not sure which decisions you mean. Can you elaborate?
My thoughts are:
Server: Juju is just plain awesome. If you manage hundreds or thousands of servers, it is Fan-Freakin'-tastic. Seriously, that alone is worth the price of admission.
They backed openstack very early, which looks like the winner. They are THE option for EC2. Heck, even Azure is picking up Ubuntu. More here: http://www.ubuntu.com/cloud If I was deploying in the Cloud, there is no other OS I would choose (and I am). IMO, it would be crazy to not use Ubuntu.
Desktop: Unity is an interesting choice, and if you asked me 3 years ago I would probably have said it was a bad choice, but seeing the state of GNOME these days, it is easily the best choice Canonical has made in the past few years.
And then there are the demo products like Ubuntu for Android, which is just plain awesome. The TV, though I'm not sure how viable it is as a commercial entity, is slick. And there is talk of a phone/tablet. Is there room for a third or fourth person in this market? With the patent problems, probably, I don't know. Though, I have to admit, I'd like to see what an Ubuntu phone and tablet would look like!
