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. > On Jul 14, 2017, at 10:27 AM, Lars Marowsky-Bree <lmb@xxxxxxxx> wrote: > > 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 _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |