On Tue, Apr 8, 2014 at 5:20 AM, George Dunlap <dunlapg at umich.edu> wrote: > > But coming back down from the ivory tower, it looks like the main > advantages put forward for ostree are: Is it fair to enumerate pros without mentioning any cons? > 1. Easy to switch between many different setups How easy? Does this require learning another configuration language and a staging box to build the image? Do you need to keep a master for every variation? Is there a way to quantify the hard/easy evaluation, say in terms of how much training it would take before trusting someone to do it in a production setting? > 2. "Atomic" updates: entire tree is changed on reboot, not piecemeal > as the RPMs are installed So, a reboot for every little change? Now we might as well throw clonezilla into the comparison (which I often use for initial rollouts, but generally not updates). > 3. A new tree is always an exact clone of the one in the repo (unlike > packages, which may diverge) So, some sort of post processing might be needed for the things that can't be exact clones. > 4. Doesn't need to re-calculate dependencies on every single host. Seems minor compared to the downtime of a reboot. And it might be possible to make yum accept a list of already depsolved packages if anyone really cared. > Adding in versioning or "list of packages" to yum may make some kinds > of deployment easier, but to make it achieve any of the things listed > above would not be so much "fixing" or "improving" yum / rpm as making > it into a different beast altogether; likely many people would not > want to use the new beast, and you'd have a fork anyway. But it wouldn't need to be 'new' or break anything it already does. > #2 is probably somewhat of an advantage; particularly if it means that > you can also atomically switch back to the previous version if it > turns out you've screwed something up. So add in the con of needing to maintain the disk space of the new/old copies. > #4 isn't a killer advantage, but if it means smaller footprint and > faster deployment, it probably is an advantage. My servers take forever to reboot - if you have to do it for every update it is not going to be faster in the long run. And, you'll need some sort of scheduling manager to control the rollout so not too many instances are down at once - which will probably be different than anything you already have. In a VM environment things might be different. -- Les Mikesell lesmikesell at gmail.com