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 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. > 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. Regards -- Andy [1] which I still hope you will merge someday -- 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
