> (though you did earlier complain about having to patch everything in isolation :P)
The problem wasn't so much that the zones needed to be patched, the problem was that they were full installs of solaris. Solaris didn't really have a concept of a 'base install', at least not without a ton of debugging and manual dependency management [0]. This meant that the only easy way to install a working solaris system was to all the packages [1]. This meant that you then needed to patch all the packages.
I think some of that got better in solaris 11(?), but I never made it that far. I think I switched to nexenta and then to debian/kfreebsd.
[0] I tried a minimal install, I got the kernel to panic by trying to enable nfs4+krb5p without having some separately packaged crypto kernel modules installed.
[1] Unless you were a solaris admin. The ones I asked said it was possible, but that I should just install everything.
As would the VM's you said you ran previously. Sadly patching is one of the biggest problems in IT. Which is where tools like Puppet come into their own (which I think you did say you run?).
> "The sparse zones were not usable because then you could not install or update software in isolation. I see the same thing on the ez-jail page:
> > "Because the basejail's copy of the userland is shared by the other jails, updating the basejail automatically updates all of the other jails. Either source or binary updates can be used."
I think that's a little deceptive. You can still install packages in the containers separate from the basejail. ez-jails would be completely useless if you couldn't. basejail is essentially just the FreeBSD core (ie it excludes /usr/local).
> "So, if an update to basejail breaks something, it breaks every jail linked to it? What if I want to test my software on FreeBSD+1?"
Then you'd have that as a container without basejails inheritance. Nobody says you have to create every jail using the same templates (though you did earlier complain about having to patch everything in isolation :P)
Personally, I tend to just take a ZFS snapshot and then rollback if I ever run into issues. It's a little lazy but works well enough for planned maintenance windows.
-----
Those arguments aside you do raise some interesting points; and I hadn't heard of Triton either. So I've definitely learned something new today. I can't really say I've had the same requirements to spin up and destroy new containers with the same frequency that you have, which would explain the differences between our experiences. For what it's worth, ez-jail does have a solution to those kinds of usages via "flavours" (loosely like VMWare VM templates). However I suspect this might still fall a little short of your specific requirements.