Quoth Alan Maguire on Tue, Feb 05, 2008 at 06:02:12PM +0000: > at present, libscf supports transactions at the property > group level, via scf_transaction_create (3SCF) and friends. > for the NWAM project, we would like to support transactions that > may span multiple property groups,
Can you explain why these property groups can't be combined into one? > and would like to be able > to load/commit an entire SMF instance if possible (to support > renaming of instances representing datalinks or IP interfaces). I've recently learned that there's no fundamental reason not to support instance rename directly in SCF, so let's be sure to file an RFE for that and document the workaround we settle on there. For now, though, I'm not sure what you mean by "load/commit an entire SMF instance". Do you mean create and populate atomically? > at present, we're getting by with a combination of the > following mechanisms, but maybe there's a better/simpler > approach we haven't thought of? > > 1: we use fcntl(2)-based lockfiles to protect multiple > consumers from colliding during commit (a system-wide > mechanism is needed, since the consumers may be > different processes, e.g. nwamcfg vs the NWAM GUI). I believe some people would say that if those processes are run by the administrator, then he shouldn't use two different tools at once. Are you planning on supporting multiple users modifying the configuration simultaneously? Otherwise, since this would only work for clients which are written to use the lockfile anyway, could you use a well-known property for this? Say, "config/change_state" or "config/lock"? When a client attempts to modify the configuration, it can check the value of the property, attempt to change it, and only proceed if the change succeeds. > 2: we always load from a dedicated snapshot (the "nwam" > snapshot), which is taken after a successful commit, and as > such represents completely committed data for the instance. I presume you don't want to use the "running" snapshot because other SMF might updated it while you're in the middle of changes? > 3: on loading data for the instance, we store the > "scf_propertygroup_t *", and use it at commit time. this > ensures that if the propertygroup has been touched since > load time, the scf_transaction_commit (3SCF) action will fail, > returning 0. this allows us to avoid lost updates - if the > editing snapshot has been updated since load, the > commit action will fail for the property group in question. This sounds like a good idea, but I'm not clear on the need. Is this for cases where you want the new property values to have a particular relationship to the old values? Like rather than setting a property to "10", you need to increment it? > 4: if commit succeeds, we refresh the instance and take > the "nwam" snapshot, since we now have a new > "last good config". > > these mechanisms combine to ensure that loaded data > has always been fully commited (since the dedicated > "nwam" snapshot is only taken after all property groups > have been committed), that multiple commits cannot collide > (via fcntl locking), and that we do not experience lost > updates (via the use of the property group handle which we > store at load time and reuse at commit). > > however it all seems like a bit of a hodge-podge, > and maybe there's a better way to tackle all of this. > it occurs to me that if it were possible to atomically > roll back the editing snapshot as a whole to a > previously-taken, "last good config" snapshot, > instance-level transactions would be a cinch, but i > don't know if that is feasible. any advice or suggestions > would be greatly appreciated. thanks! That might work, but I suspect it would be a workaround for a better change model. I'm planning on introducing instance-wide transactions in the Enhanced SMF Profiles project, but it's a ways off. Anyway, perhaps we should file an RFE for instance-wide transactions, to collect the discussion. David
