On Fri, Jul 2, 2010 at 3:00 PM, Guido Trotter <[email protected]> wrote:
> On Fri, Jul 2, 2010 at 2:46 PM, Luca Bigliardi <[email protected]> wrote: > >> Mh yeah, it's not foolproof (a fool can do --disable-drbd-storage and then >> create a drbd instance). >> >>> Possible solutions: >>> - another explicit "drbd enabled or not" parameter >> >> I'd prefer to not add another parameter >> >>> - if this parameter is set to none disallow creating drbd instances. >>> this will trigger the code but at least no flip the parameter under >>> the user's nose. >> >> Which kinda stretch the drbd usermode helper check concept.. >> > > I agree with iustin's solution to the problem of triggering the upgrade code. > Now, regarding allowing to create drbd instances when disabled or not: > > Right now you have the following: > - if a cluster has drbd instances, you can't pass --disable-drbd-storage > - if a cluster has --disable-drbd-storage you can still create drbd instances > > This is not nice, and non-simmetric. I believe we should either: > - not allow the drbd instances to be created if > --disable-drbd-storage has been passed > or > - not call the flag --disable-drbd-storage and \ > - allow --disable-drbd-helper-check (or whatever) to be set/unset > even if drbd instances exist > (and then we can keep the current behavior of allowing new drbd > instances to be created if the helper check is disabled). > > Basically we have to decide if this is just a usermode helper check > (in which case the flag name and the restriction are wrong) or a way > to totally disable drbd storage (in which case the flag name is right, > but not the behavior, completely). For the name please have a look at the cover letter. > > Thanks, > > Guido >
