David Bustos wrote: > Quoth Alan Maguire on Wed, Feb 06, 2008 at 02:53:05PM +0000: > > >> 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. > > ... > so we should stick with multiple property groups in this case? >> 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. we could do something similar here in the short term then i guess. > It would be better to have a general mechanism in SCF, > though. > > agreed. > ... > >> 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. > > excellent! > ... > >>>> 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? > > i think so. >>> 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? > > nope. under the current model, using fcntl with the F_SETLK command, if the process holding the lock goes away, it can be reacquired. maybe if we used the pid as an identifier value for the lock property in SMF, and if that process no longer existed, we could allow the caller to reacquire it.
>>>> 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? > > not off the top of my head, which may suggest that this capability may not be strictly necessary. so to summarize what we've discussed so far, - we're going to shoot for a native rename capability in SCF - we should use separate property groups for each administrative object controlled by an instance - as much as possible we should try to use SMF itself to implement the system-wide locking needed for instances. - regarding instance-level transactions, we'll need a short-to-medium term approach prior to their availability as part of extended profiles. have i got this right? thanks! alan
