Quoth Alan Maguire on Wed, Feb 06, 2008 at 02:53:05PM +0000: > David Bustos wrote: > > 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).
Right, multiple property groups seems appropriate when they represent separate configuration objects. > 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. Yeah, let's try to avoid that. ... > 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. If I understand you correctly, I think svccfg already has this problem today. We solved it my making sure general/enabled is the last property to be created and making svc.startd ignore services without general/enabled. It would be better to have a general mechanism in SCF, though. ... > 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? No, it could be done before, which would probably be easier anyway. ... > >> 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. Ok. If it turns out that's really expensive to implement, would it be ok to leave it out in the short-term? > > 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. Yeah, I was thinking of the property as a mutex. If it was set to "unlocked", then you would try to change it to "locked" before doing anything else. If someone else locked it before you, the commit would fail, you'd reread the property, and see that it was now "locked". Then you'd have to poll until the owner changed it back to "unlocked". The big problem is that there's nothing to unlock the property if the client dies or forgets to unlock it. Does file locking have that problem? > >> 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. I think some people would say that refreshes are only supposed to be triggered by the administrator, so he shouldn't be making the two modifications simultaneously. Of course if we have automatic configuration changers, like I presume NWAM will be someday, then that's not the case anymore. That's one of the reasons I wanted to move to an instance-wide transaction model for enhanced SMF profiles. > >> 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. Can you give an example of a configuration value where the user wants the new value to have a specific relationship to the current value, rather than a value the user thinks of a priori? David
