The point that nobody seems to be making is that this degree of rigour is essentially a requirement for some classes of systems, ie. the OS platform upon which you deploy applications becomes a named, versioned, tested entity with its own repo and changelog, which can be rapidly provisioned at any of its versioned states, rolled back, and have specific versions of specific applications tested against it. This is not always required, but is definitely good practice in all cases.<p>This is the part where I suggest docker people broaden their scope to include such... "devopsy" concerns around virt deployment. In my own system used internally within my company we have this distinction .. the platforms are called PEs (platform environments) and the applications are SEs (service environments). Combining both produces a SIN (service instance node) on a particular CP (cloud provider).<p>While I really support docker and they probably get annoyed at me always commenting on their project and coming across as being slightly critical, in all honesty docker irritates me because it leaves all this sort of business out of scope. But I think they are possibly also heading in this direction. :)
(disclaimer: I'm a developer on the Image Packaging System project: <a href="https://java.net/projects/ips/" rel="nofollow">https://java.net/projects/ips/</a>)<p>I think there's been some editorialising of the title as I don't see that the author of OSTree claims that it's a "robust" solution (alone).<p>With that caveat, without filesystem snapshot support, OSTree really isn't a complete solution (as the original author points out).<p>On Solaris 11+, there are generally two update scenarios for package upgrades:<p>1) pkg update [name1 name2 ...]<p><pre><code> no packages have new or updated items tagged with
reboot-needed=true
pkg will create a zfs snapshot
pkg will create a backup boot environment
perform update in place on live root
if update fails, will exit and tell admin name
of snapshot so they can revert to it if desired;
will also print name of backup BE
if update succeeds, will destroy snapshot and exit
</code></pre>
2) pkg update [name1 name2 ...]<p><pre><code> one or more packages have new or updated items tagged
with reboot-needed=true
pkg will create a zfs snapshot
pkg will clone the live boot environment
pkg will perform update on clone
if update fails, will tell admin name
of clone BE so they can inspect it and exit
if update succeeds, will activate clone BE,
destroy snapshot, and exit telling admin name
of new clone
</code></pre>
Put another way, on Solaris 11+, the "default practice is the best practice." This is the advantage of integrating the package system with the native features the OS itself supports.
While I like the idea of atomic upgrades, the idea really should be made to work without requiring a full reboot. The update procedure could be something like:<p>1) updater makes a private snapshot of the filesystem<p>2) updater writes its changes to the private snapshot while the rest of the system gets served by unchanged FS<p>3) updater stops affected services<p>4) the updated snapshot is swapped in (atomically)<p>5) services are restarted
From <a href="https://people.gnome.org/~walters/ostree/doc/ostree-package-comparison.html" rel="nofollow">https://people.gnome.org/~walters/ostree/doc/ostree-package-...</a>:<p>> OSTree only supports recording and deploying complete (bootable) filesystem trees. It has no built-in knowledge of how a given filesystem tree was generated or the origin of individual files, or dependencies, descriptions of individual components.<p>Um-m, isn't this what snapshots (e.g. LVM snapshots) are for? Correct me if I'm wrong.