On Fri, Feb 10, 2012 at 1:45 AM, Andy Grover <agrover@xxxxxxxxxx> wrote: > On Thu, Feb 9, 2012 at 8:13 PM, Dax Kelson <dkelson@xxxxxxxxxxxx> wrote: >> I don't think that is a good idea. It violates the principal of >> least surprise [1]. > > A good point. However, I think it may be more apt to compare against > existing storage appliances, which persist configuration. The nightmare > use case for me is: > > * admin sets up huge cluster of vms, all mounted off an LIO box, admin > never saves config > * everything runs fine until 6 months later, when the LIO box is > rebooted for security updates and the entire LIO configuration is lost, > and the admin comes hunting for us I understand. I think Dax's suggestion of a big fat warning on exit if the config has not been saved is probably the best option to avoid this problem. > > In addition, requiring explicit save is tricky when we start looking at > adding support for remote storage management APIs like SMI-S that assume > resources persist across power cycles. (I guess we could require > saveconfig from targetcli but autosaveconfig if configured remotely? But > then we're inconsistent with ourselves!) > > On 02/09/2012 12:47 PM, Jerome Martin wrote: >> I agree. This is why I implemented the way it is. >> The idea initially was also to be able to test a new config, and just >> have to reboot to revert to the known good one in case the new one >> breaks too many things and the admin gets cornered. > > targetcli-fb[1] saveconfig takes a filename parameter, so the admin > could save to backup.json, do whatever, and then restore back to > backup.json without rebooting. lio-utils is backuping the previous configs before writing a new one, all are available in /etc/target, sorted by date. However we lack a targetcli command to explicitly load one of these, has to be done manually for now > >> If there is enough expressed need for this, than at the very least >> it should be an option. > > An option sounds good. I'll try adding an auto_save_on_exit and see how > that works out. <nod> > > Regards -- Andy > > [1] which I still hope you will merge someday I still hope I will be able to merge it. You've been explicitly refusing to use our contribution terms (either contribution agreement or MIT licensing) which we explained that unfortunately is not something we can easily change for now. So I just _can't_ merge as is. And as discussed in a previous thread, our contribution terms are far more liberal than many successful OSS projects, including ones sponsored by your employer, so I can't really see why you are being so stubborn about it :-( But that's life, you deserve to have your opinions respected even if we do not understand or share them. Best Regards, -- Jérôme Martin -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
