Bug#576511: Info received (Bug#576511: drbd8-utils: Ships with violent default actions)
On Mon, Oct 29, 2012 at 11:02:39AM +0100, Philipp Hug wrote: > > In fact, if you had been listening to me from day one, you'd realize > > that I'm not even asking you to actually fix this problem. > > I'm merely asking you to make the users who aren't using your personally > > preferred use case, but are nevertheless using an apparently valid and > > supported use case, aware that these otherwise undocumented defaults are > > going to be causing them data loss. > > As I said before, please go ahead and submit a possible solution (e.g. patch) > If you can live with a disclaimer at the top of /etc/drbd.conf: like > ## WARNING > ## > ## Please review the defaults in /etc/drbd.d/global_common.conf, > ## especially the error handlers, as they reboot the machine in case > of drbd failure, > ## before enabling any drbd resources. > ## > > that would be perfectly fine to me. > > > In retrospect, all this is really ridiculous. I've made every good-faith > > effort to be constructive in this bug report, and in turn you've just thrown > > condescending platitudes at me in an apparent effort to avoid doing anything > > I had to use google translate to figure out what you're saying.. > That was for sure not my intention. I was just worried, that changing > the default makes things worse. And I assumed that's what you wanted. > As I said before, I'm fine changing comments in the configs to warn users. > > > about this in wheezy (otherwise, what's the point of using a non-RC > > severity?). I suppose you can continue to do so, but that will simply force > > me to request that this package is removed from wheezy elsewhere, given that > > it's unfit for release both because of a software problem and because of a > > human problem. > > Well, yes, IMO, this is a wishlist bug, that's how I set the severity > initially, because changing the defaults could make it worse and needs > further discussion. > wishlist > for any feature request, and also for any bugs that are very > difficult to fix due to major design considerations. > > So, please answer me if adding the comment is an acceptable solution > for you and I'll upload a new version. I'm not sure if you realize it or not, but you've managed to treat me with pure condescension once again. If you "had to use google translate to figure out what I was saying", I really have to suggest at this point that you steer clear of maintaining packages, because English comprehension is supposed to be a required skill in interacting with bug reporters. (That goes double for complex software such as DRBD, that entails non-trivial bug reports.) I admit I'm not a native English speaker, but my messages here all consisted of reasonably simple English. And just so I don't get accused of complete failure to be constructive at this point, even in these circumstances where I'm being repetitively insulted: to answer your specific suggestion - do we have any reason to believe that all users who don't want the reboots/halts will take a look at the specific /etc/drbd.conf file? The generic location seems reasonable enough, but doing just that still means putting potentially critical information in a single file that may not be read, and contradicting the other available documentation that I've referenced earlier. Specifically, in case of drbd.conf, I for one remember creating my /etc/drbd.d/*.res files without looking at either drbd.d/global_common.conf or drbd.conf, because I had assumed that on a clean installation there wouldn't be any worrying aspects in the bare defaults. If we want to continue applying these harmful defaults, we should be telling that to people in all the relevant documentation. It won't mean we completely prevented harm to them, but at least then we can say we made an effort. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#576511: Info received (Bug#576511: drbd8-utils: Ships with violent default actions)
> In fact, if you had been listening to me from day one, you'd realize > that I'm not even asking you to actually fix this problem. > I'm merely asking you to make the users who aren't using your personally > preferred use case, but are nevertheless using an apparently valid and > supported use case, aware that these otherwise undocumented defaults are > going to be causing them data loss. As I said before, please go ahead and submit a possible solution (e.g. patch) If you can live with a disclaimer at the top of /etc/drbd.conf: like ## WARNING ## ## Please review the defaults in /etc/drbd.d/global_common.conf, ## especially the error handlers, as they reboot the machine in case of drbd failure, ## before enabling any drbd resources. ## that would be perfectly fine to me. > In retrospect, all this is really ridiculous. I've made every good-faith > effort to be constructive in this bug report, and in turn you've just thrown > condescending platitudes at me in an apparent effort to avoid doing anything I had to use google translate to figure out what you're saying.. That was for sure not my intention. I was just worried, that changing the default makes things worse. And I assumed that's what you wanted. As I said before, I'm fine changing comments in the configs to warn users. > about this in wheezy (otherwise, what's the point of using a non-RC > severity?). I suppose you can continue to do so, but that will simply force > me to request that this package is removed from wheezy elsewhere, given that > it's unfit for release both because of a software problem and because of a > human problem. Well, yes, IMO, this is a wishlist bug, that's how I set the severity initially, because changing the defaults could make it worse and needs further discussion. wishlist for any feature request, and also for any bugs that are very difficult to fix due to major design considerations. So, please answer me if adding the comment is an acceptable solution for you and I'll upload a new version. Thanks, Philipp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#576511: Info received (Bug#576511: drbd8-utils: Ships with violent default actions)
Control: severity -1 critical On Sat, Oct 27, 2012 at 12:54:11PM +0200, Philipp Hug wrote: > control: severity -1 important > > Josip, > > Please don't upgrade the severity of this bug. > > The defaults actually prevent further data loss for the majority of drbd > users. > In the normal setup the drbd device is the main storage device so the > defaults make sense. > > If you have a suggestion for a better default please go ahead and post it. *facepalm* I have quoted chapter and verse from both the BTS manual and the DRBD manual that support my claims. I've pasted the log messages from my own data loss situation that happened because of this. What you assert is the "normal setup" is both simply orthogonal to the problem, and it's actually not defined to be so by your own documentation. Imagine for a moment if, when encountering an I/O error, all other block device drivers decided to instantly reboot/halt the machine. One disk at /dev/sdc has an unreadable block - poof, everything else you've been doing on the other 5 disks in the machine since the last disk flush is gone. You think this is a reasonable default that the users should expect? In fact, if you had been listening to me from day one, you'd realize that I'm not even asking you to actually fix this problem. I'm merely asking you to make the users who aren't using your personally preferred use case, but are nevertheless using an apparently valid and supported use case, aware that these otherwise undocumented defaults are going to be causing them data loss. In retrospect, all this is really ridiculous. I've made every good-faith effort to be constructive in this bug report, and in turn you've just thrown condescending platitudes at me in an apparent effort to avoid doing anything about this in wheezy (otherwise, what's the point of using a non-RC severity?). I suppose you can continue to do so, but that will simply force me to request that this package is removed from wheezy elsewhere, given that it's unfit for release both because of a software problem and because of a human problem. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#576511: Info received (Bug#576511: drbd8-utils: Ships with violent default actions)
control: severity -1 important Josip, Please don't upgrade the severity of this bug. The defaults actually prevent further data loss for the majority of drbd users. In the normal setup the drbd device is the main storage device so the defaults make sense. If you have a suggestion for a better default please go ahead and post it. Philipp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#576511: Info received (Bug#576511: drbd8-utils: Ships with violent default actions)
Following on Philipp's comment, I went looking for explanation in the old template config file changes, and found the sysrq calls added with no obvious explanation here: http://git.drbd.org/gitweb.cgi?p=drbd-8.3.git;a=commitdiff;h=3b4452d69b4371dbeee5a38f2e248a6360c14c77 But this is still conditional on the on-io-error setting, which remains set to detach. With the two reboot states, there's no avoiding the sysrq call. In any case, he assumption that DRBD is the sole block device backend on the system is wrong, and the package can and should take care of it. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
