On Mon, Jul 16, 2018 at 8:06 PM Anthony D'Atri <aad@xxxxxxxxxxxxxx> wrote: > > > >>> Putting it in the mgr also would allow us to do things like scheduling > >>> time of day to do replacements, or maybe adjust recovery throttling > >>> automatically, or whatever else we decide would improve the overall > >>> process. > >> > >> +1 to putting features in mgr if that lets us avoid having as many different > >> implementations of those features as there are orchestration tools. > > > > BTW I am not saying to *not* put it there, I am mostly interested in > > finding what are the gaps that ceph-volume can help, like > > mounting/unmounting, systemd, > > dmcrypt, etc... > > > Forgive me if I've missed something, but one advantage of using the mgr is also visibility across the cluster, notably to restrict repaving paralleism to a single OSD per host / failure domain / cluster as desired. > > That said, if something like this gets implemented, here's a vote to generalize it a bit to a generic repaver, not just Filestore -> Bluestore. Some of you may remember the "-n size=65536" nightmare I fought in the past. I dreamt of a daemon that would just run in the background repaving OSDs, but at the time lacked the resources to develop one that would be safe to let loose in a brittle production cluster. The underlying bits will all be quite generic -- the process for doing a filestore->bluestore migration is highly reminiscent of handling a drive replacement on a failure, and the only difference between a failure and a repave is whether the OSD jumped or it was pushed :-) BTW there's already an interesting opportunity for someone to write a chaosmonkey-type ceph-mgr module that periodically does things like taking an OSD out and letting the cluster rebalance, randomly killing an MDS from time to time, etc. John > Or even more abstracted, a generic OSD iterator that would apply a given script / task to each OSD subject to the obvious constraints. This would seem to be too big a bite to take just to repave but I can dream ;) > > > -- aad > > -- > 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 -- 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
