Christine Tran wrote: > 1) This is not what I intend to happen. In my mind, something like > logging is OK for SMF control but I didn't expect my iSCSI configuration > to enter the repository. We've had a few threads about what should be > configurable under SMF, and the original answer used to be "everything" > but for practicality this is not a good or do-able answer.
System-wide configuration snapshots are great in that they let you easily restore the system to a previous configuration, even if you don't remember all of the things that you did. They are less than great in that they are a big hammer; they aren't directly useful for undoing that one change that you made last week. One could imagine keeping a change log and offering a user interface that would let you see the changes that had been made to the system, probably sortable and filterable by by time and what component was affected, and allowed you to undo (by changing back) one or more previous changes. I don't think SMF has that (yet). > 2) In a simpler, less nuanced view, what I didn't use SMF to configure, > I shouldn't lose through SMF. [...] Yes and no. I think we'll increasingly see SMF layered underneath things. For instance, my project, xVMOC, layers its service enable/disable on top of SMF. You can use our tools to enable and disable our services, and under the covers they do it with SMF. (Yes, it's arguably wrong that we don't arrange that you can use the SMF tools directly; see the related discussions about how to manage groups of services in a coordinated fashion. We also want to offer a single mechanism that works on both Solaris and Linux.) This is a good thing in that SMF snapshots can be used to undo changes that were done by some random program without your direct involvement. (Suppose, for instance, that your iSCSI configuration was buried deep inside some product's installer. Wouldn't it be cool if you could say "get my system back to the way it was yesterday, no matter how the changes got made"? That's the idea.) OTOH, because you can't rely on it and can't be sure what will and won't be affected, there's definitely an opportunity for confusion. > 3) ZFS zvol target info is kept somewhere else, obviously, because I > didn't lose those. This inconsistency is a burr. Absolutely, the inconsistency is wrong. (IMHO.) > Should I open up a bug about this usage, it seems like it could be > "friendlier" somehow, or just get used to this, the way of the future? I personally think that unified configuration, including system-wide snapshots, is indeed the way of the future. I believe it will be a rocky road getting there; we will need additional tools and user interfaces, and there will be a long transition period getting services to play nice with this infrastructure. (One thing that might make a good RFE would be a way to hook a traditional config file into SMF so that it is saved and restored as part of a snapshot. Seems like that would be a good way to transition a legacy service into participating in the system-wide snapshot mechanism.)
