Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 18/02/2016 22:34, Lars Ellenberg wrote: > Of course, eventually we need to provide a more or less convenient way > to move 8.4 clusters to 9. And we will. But for now, if you have an > existing, working, production DRBD 8.4 cluster, I see no reason at all > to move that to DRBD 9, not in this year anyways. Aha, (light bulb moment). I think this perhaps clarifies the correct (current) state of things. Please correct my statements below, as I suspect what I think is flawed... 1) A new production install should use DRBD9 because it is the most stable, the best performing, and has the really cool drbdmanage "magic" 2) If currently using drbd 8.4 (in production), there is no need or point in upgrading to drbd 9 (yet) 3) If we want to use the multi-peer technology in DRBD, then you can upgrade to drbd 9 and continue to use manually managed config files 4) If we want to use the multi-peer technology in DRBD, then you can upgrade to drbd 9 and manually convert/migrate to drbdmanage I'm currently in the situation of 3 or 4, my concerns are that drbd9 is not yet production ready/stable, and that documentation for doing 3 or 4 doesn't seem to be complete. You say there is no tool for 4 because it would need to handle every situation, and people do weird stuff (I agree with this view BTW, even if it would be nice to eventually get a tool that handles 70% of cases), however, it should be possible to at least document one example (which is a fairly common scenario) and leave the application/extension of this example to the admin. Can you alleviate my concerns in relation to DRBD9 being stable? I'd really like to use the multiple peer technology, and from linbit reports, there are also some significant performance gains available. I don't mind dealing with "rough edges" like difficult migration tools, or even lack of documentation, as long as things work reliably once configured. Regards, Adam