Quoth John Beck on Tue, Jun 12, 2007 at 07:49:21PM -0700: > David> The second draft of the Enhanced SMF Profiles design is now available > David> at http://opensolaris.org/os/project/smf-profiles/Design ... > > 1.1.1 > > * Why does a manifest get re-imported at boot even after an explicit > `svccfg import`?
User-invoked svccfg import does not store the hash of the manifest into the repository. On boot, SMF believes that the manifest has not been imported, and does it again. If there has truly been no change, then svccfg import should recognize this and not modify the properties. This project should make svccfg import store hashes for all manifests, as well as their paths. This should prevent manifests from being reimported, and also allows the boot code to distinguish between manifests which have been removed from /var/svc/manifest and manifests which were imported from outside of /var/svc/manifest. I don't see any text which implies this, so I presume you asked because you were curious. > * What do you mean "Properties ... can have any number of values ..."? Properties actually hold value sets. They can have one value, multiple values, or no values. A single dependency can declare multiple targets, in which case we store the FMRIs as distinct values of the same property. Try "svcprop -p identity/entities sysidtool:net". This is one of the reasons that svcprop's output format can be relatively complicated. Moreover, the values are not ordered, so some people think this makes writing property-using programs more difficult than necessary. > 1.1.2 > > "Only SMF-initiated snapshots are available today;" is this true? I.e., > is the interface really completely internal or merely project private? The interface for taking snapshots is project private. This is primarily because we don't have functionality for administrators to determine how space is being used in the repository database file. > 2.1.1 > > A lot of this sounds good, but is written at a very theoretical level. > Specific examples would make it much easier to understand. I noticed > this particularly in the Multi-Package Profiles section, though it > applies to others. Ok. > 2.1.2 > > In the Conditional Profile Order section, this text: > > this project will provide a mechanism for condition developers ... > is confusing, particularly the "will" vs "could" in the first sentence. > If I understand the meaning correctly, it would be better to end the > first sentence (and paragraph) after "exclusivity", then start a new > sentence (and paragraph) to express the "maybe in the future" topics. Ok. > 2.2.2 > > * Note: libwladm has been subsumed by libdladm. > * Please s/interface/network interface/ where appropriate for clarity. Ok. > 2.2.6 > > Why did you list ns_nis in admin instead of ns_dns as SXDE seems to do now? Because I didn't know it did that. > 2.3.4 > > * I don't follow the first bullet under "Incompatibilities". When a user customizes the general/enabled property of a service with svcadm, today the initiator is not noted -- the property is just changed. If another tool comes along and wants to change the default value of general/enabled, it's so hard to tell whether the property has been customized that nobody tries, and they just change the property, disregarding the user's intended customization. For example, system/dbus disabling itself inside of zones. This project will make it so that that customization will stick, which can lead to situations where the user actually wanted the new default, but because he had made a customization, he didn't get it. > * nit: s/who's/whose/ > > 2.3.9 > > Again, examples would really help clarify this, especially in the "Service > implementation" section. Ok. > 2.5 > > * Condition Strings: modulo stated caveats, this sounds like a Good Idea > * Sophisticated Condition Constraints: not sure of details, but something > like this should be supported > * Modification Interfaces: probably; Solaris in general has too much cruft > * Runlevels, NWAM, and the service level profiles > * multi-user-server does seem to be multi-user + a bunch of net services, > but there are other net services which multi-user-server does not > depend on. Hmm, but that's new with SMF, isn't it? In Solaris 9, if you wanted your service to be started on boot, then you had to choose one of single-user, multi-user, or multi-user-server in which your service should start. (Unfortunately, that statement doesn't seem to lead me to an epiphany.) > * multi-user depends mostly on local services, but it does depend on some > net services as well. Aren't they all either clients or capable of local service? David
