On 2017-07-14T14:12:08, Sage Weil <sage@xxxxxxxxxxxx> wrote: > > Any thoughts on how to mitigate this, or on whether I got this all wrong and > > am missing a crucial detail that blows this wall of text away, please let me > > know. > I don't know; the requirement that mons be upgraded before OSDs doesn't > seem that unreasonable to me. That might be slightly more painful in a > hyperconverged scenario (osds and mons on the same host), but it should > just require some admin TLC (restart mon daemons instead of > rebooting). I think it's quite unreasonable, to be quite honest. Collocated MONs with OSDs is very typical for smaller cluster environments. > Is there something in some distros that *requires* a reboot in order to > upgrade packages? Not necessarily. *But* once we've upgraded the packages, a failure or reboot might trigger this. And customers don't always upgrade all nodes at once in a short period (the benefit of a supposed rolling upgrade cycle), increasing the risk. I wish we'd already be fully containerized so indeed the MONs were truly independent of everything else going on on the cluster, but ... > Also, this only seems like it will affect users that are getting their > ceph packages from the distro itself and not from a ceph.com channel or a > special subscription/product channel (this is how the RHEL stuff works, I > think). Even there, upgrading only the MON daemons and not the OSDs is tricky? -- 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
