hi David David Bustos wrote: > 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? > > in most cases, the issues centred around rename. the idea was we would read in a representation of an instance which consisted of its application property groups and dependencies, modify that in-memory representation and later commit (in the case of rename, we'd need to adjust dependencies, so we needed a representation of those too). if rename could be supported natively in libscf, the need for multiple property groups would not be so pressing i think. i'll cite a few examples where multiple property groups may be appropriate.
one area where i think they make sense is in the context of IP addressing information associated with an IP interface instance. we can have multiple address information groupings, each of which would consist of an address acquisition method, optional address etc (these would correpsond to the associated IPv4 and IPv6 interfaces). however, there are other ways to tackle this particular problem. making the properties multivalued would work, but i'd like to keep the grouping between address acquisition method and related properties. since the repository doesn't guarantee order, we can't rely on value n of propA is related to value n of propB, so we could just use a single-valued property with a delimiter to store multivalued address acquisition methods, and another single-valued property string to store multiple addresses. another case is for datalink SMF instances, we need to store both mutable configuration properties, and immutable data about the datalink, such as the linkid. i was thinking it might make sense to distinguish between these different classes of property via different property groups, but again i don't think they have to be in separate property groups (the NWAM API can simply prohibit user modification of the immutable properties). so, in short, i think we can modify our data model to hold all datalink/IP data in a single property group for datalink and IP interface instances respectively, assuming the above suggested changes are reasonable. the one area i'm unsure about is dependencies. if a future libscf rename operation fixed all references to itself in dependents as part of the rename operation, that would certainly hep, but i think we're still left with the case of instance creation, where after creating the instance, we need to both create the application property group for the datalink/IP interface properties, and create one or more dependency property groups (e.g. the IP interface instance will depend on the underlying datalink instance). maybe we can relax atomicity constraints for the create operation though if it's the only case that is problematic. >> 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. > > fantastic! i've filed 6659863 need native SMF instance rename support in libscf ...to track this. now would rename support depend on extended profiles, or could it be pursued independently of that work do you think? > For now, though, I'm not sure what you mean by "load/commit an entire > SMF instance". Do you mean create and populate atomically? > > yep, see above. >> 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? > > the intent is to guard against edge scenarios such as simultaneous updates from the CLI and GUI. while we would hope such things won't happen, we'd like to ensure that if they do, the configuration represents the intent of the most recent committed operation. > 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. > > it'd certainly be nicer to manage updates exclusively via SMF without introducing file locking. the only problem here is that the property could have changed since we read it in, and we'd then erroneously proceed with the update. i guess we could catch such scenarios via scf_transaction_commit(), if it returned 0 we'd know someone else has touched the properties. > >> 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? > > exactly. if a commit operation spanned two property groups, it would be possible to refresh at any point and end up with a not-fully-committed running snapshot. i think these snapshot issues go away if we can keep all properties within a single property group though. >> 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? > > exactly. the thinking was that since a transaction might be changing properties based on its current view, that it should notify the user that the view has become outdated at commit time. >> 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. > > sure - i've filed 6659868 need native instance-level transaction support in libscf thanks! alan
