Sorry to have let this slipped. David Bustos wrote: > Quoth Christine Tran on Mon, Apr 07, 2008 at 04:58:13PM -0400: >> I then set some logging level and refreshed. >> # svccfg -s iscsitgt setprop iscsitgt/qlog-lvl = integer: 0xffffffff > > Is this supported? If I recall correctly, the target configuration was > private and to be modified via iscsitadm.
I don't think so, this is not documented anywhere, someone told me how it's done. >> Some time later I needed to stop logging, because I didn't check for the >> original value of iscsitgt/qlog-lvl before I changed it, I decided to >> rollback to the initial snapshot. After the refresh, my "ponies" target >> disappeared, but all the zvol targets remained. This bothers me for a >> few reasons: >> >> 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. > > Can you explain what is different about those pieces of configuration > that make you think they should be stored differently? One is config info directly pertinent to the operation of the application. The other is administrative info. One could say both types of info direct the operation of the apps: what targets, where to log; I think I'm used to pertinent stuff in name-of-app_config and admin stuff in Solaris. If it's just a matter of getting used to it then it's not that big of a problem. >> 2) In a simpler, less nuanced view, what I didn't use SMF to configure, >> I shouldn't lose through SMF. I used iscsitadm to create my target, >> while it's acceptable that I could lose my target by blowing away a >> config file or trashing a device label, I didn't expect it to be in an >> SMF snapshot. Should I expect this going forward? This seems an admin >> trap to me. There didn't seem to be a way to set debug level from >> iscsitadm directly. > > You should expect this going forward. Perhaps we should mandate that > even when configuration is stored in private properties in the > repository, that they are in the repository at all should be documented > for the administrator's benefit. I'm surprised that info makes it into the SMF repository, because iscsitadm is a million miles away from svccfg. Docs here would help. > I have wondered if we should implement a way to revert individual > property groups or properties from a given snapshot. Do you think that > would have helped here? The bigger question for me, though, is "is SMF ready to be a configuration manager", on top of what it does already. The syntax to examine the service is intimidating. I don't think a way to revert single properties would have helped here (I didn't expect the target info to be in the snapshot at all), but a "show me the delta" may have clued me in. I dunno ... I've been thinking for a while about this, and I can't decide if this is a special circumstance that tripped me up (perfect storm of UFS, ZFS, iSCSI logging, SMF snapshot), or will this general behavior trip up the majority, if SMF is progressing this way. > Yes, I believe shareadm similarly exposes differences in ZFS's and UFS's > ability to store filesystem configuration. If consistency is mandatory, > then it seems that the tradeoff becomes utilizing ZFS's new capability > vs implementing similar capability in UFS. Do you think consistency is > important enough to justify enhancing UFS? I'm leaning toward "probably not". This can be taken care of with a note in the man pages or the ZFS guide. This is just a gap between what's expected and what really happens, it's not really a usability problem. CT
