Let me just jump in here since there has been some discussion about this.
The most important fact first: Jails in FreeNAS are a hack. I get that they're useful to a lot of people, but the way they were implemented in FreeNAS (and this goes way back) was really quick-and-dirty and certainly wouldn't have been approved as a feature if I'd been on the approval chain back when they were first proposed. It's too late to put the genie back in the bottle, but if I had my way with the current implementation, it would simply be ripped out entirely until a properly architected solution could be put in its place. What's there is not architected at all, it's just a band-aid.
The second fact: Templates are created outside of the release engineering process using dark and arcane magic involving poultry sacrifice. This makes them hard to update, and even once they're updated, there is no way for existing jails to benefit from this due to the reasons outlined above. Every template is nothing more or less than a dumb tarball which is extracted for the first time into jails of that (template) type and then never referenced again. On the plus side, of course, we did make the template system extensible so if you want to create your own tarball of an up-to-date FreeBSD distribution and then use that on your box as a starting point for all future jails, you can certainly do so. It won't help you with updating, but you'll at least start from a better spot.
The third fact: Jails themselves require VIMAGE to be properly isolated from the host (FreeNAS) networking environment, and that comes with its own issues. There are only so many things you can do from a VIMAGE jail without panicking your box, because VIMAGE as a feature still is not finished (don't combine it with pf, for example - that's an instant panic). If you don't use VIMAGE, then any and all networking ports you use from the jail are now unavailable to the host machine because everything is sharing a common network stack, and jails can also easily collide with one another.
Basically, jails as a FreeBSD feature were never meant to be the light-weight virtualization solution people are making them out to be. They're just really thin security boundaries that come with a host of limitations. The most reasonable way forward for FreeNAS 10 is going to be to use bhyve (which may also require improvements to make it fully suitable for the purpose, but it's at least moving in the right direction) and create genuinely virtual environments, both FreeBSD and Linux, that can then be updated using whatever OS-dependent tools are best suited to the purpose (freebsd-update, apt-get, whatever).
This is also why I am predisposed to close most jail-related enhancement requests or put them in the "far distant future" bucket - there's just little point in investing additional time and resources into a mechanism that is always going to be a bit too fragile, and unsufficiently isolated, from the FreeNAS host system to meet the needs of what people really want to do. Processors are also steadily increasing in power, RAM and disk storage is going up, and it's already the case that even reasonably-powered machines can run multiple VM instances without undue overhead. Unlike jails, those VMs can also be properly paused, snapshotted, resumed, and so on, and they can run "foreign" operating systems with full fidelity, unlike Linux jails which were such a fragile hack that the FreeNAS project promptly removed them 2 releases after adding them as a bad idea (they failed to work for a lot more things than they did work for).
All that said, if there is an easy way of making templates "fresher" or otherwise making them a less voodoo-intensive part of the release engineering process, I'm willing to look into that since jails are going to be around, hated by their implementors or not, for awhile. I'm discussing that with the team.
Thanks.
