It was required for Bobtail to Cuttlefish and Cuttlefish to Dumpling. Exactly how many mons do you have such that you are concerned about failure? If you have let’s say 3 mons, you update all the bits, then it shouldn’t take you more than 2 minutes to restart the mons one by one. You can take your time updating/restarting the osd’s. I generally consider it bad practice to save your system updates for a major ceph upgrade. How exactly can you parse the difference between a ceph bug and a kernel regression if you do them all at once? You have a resilient system why wouldn’t you take advantage of that property to change one thing at a time? So what we are really talking about here is a hardware failure in the short period it takes to restart mon services because you shouldn’t be rebooting. If the ceph mon doesn’t come back from a restart then you have a bug which in all likelihood will happen on the first mon and at that point you have options to roll back or run with degraded mons until Sage et al puts out a fix. My only significant downtime was due to a bug in a new release having to do with pg splitting, 8 hours later I had my fix. > On Jul 14, 2017, at 10:39 AM, Lars Marowsky-Bree <lmb@xxxxxxxx> wrote: > > On 2017-07-14T10:34:35, Mike Lowe <j.michael.lowe@xxxxxxxxx> wrote: > >> Having run ceph clusters in production for the past six years and upgrading from every stable release starting with argonaut to the next, I can honestly say being careful about order of operations has not been a problem. > > This requirement did not exist as a mandatory one for previous releases. > > The problem is not the sunshine-all-is-good path. It's about what to do > in case of failures during the upgrade process. > > > > -- > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) > "Experience is the name everyone gives to their mistakes." -- Oscar Wilde > -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
