David Bustos writes: > The second draft of the Enhanced SMF Profiles design is now available at > http://opensolaris.org/os/project/smf-profiles/Design , along with a PDF > at http://opensolaris.org/os/project/smf-profiles/Design/design.pdf .
This is an exellent and thorough document. Nice work! Sorry for the unreasonably long delay in getting the comments to you. p12: completeness flag - Use a flag? or something more nuanced e.g. complete, customization, in-progress? You could make it a string and delay introducing values beyond "complete" in order to allow extensibility later. p13-14: Conditional configuration - I'd like to hear from developers and administrators whether they think Conditions are obvious and intuitive. The alternative approach here would be for the examples you've offered to create a service instance which reflects the condition, and use dependencies. We'd of course have to offer either a new type of dependency and/or not report the dependent service as faulty when it's offline due to this type of relationship. We could also consider not showing a condition service in the default svcs output. It is notable that Conditions will need to feed into the svcs -x diagnosis of a service's state. Using services to represent conditions could also make developer-delivered conditions available in Phase 1. The main place Conditions shine is if there's configuration beyond whether a service should run that needs to be Conditional. If both admins and developers do find the new concept more obvious than a dependency, then I'm willing to put aside my concerns about introducing Conditions rather than utilizing the existing dependency mechanism to solve these problems. I'd just like to hear about whether folks who would need to use Conditions think they're an obvious concept, and think (based on the description in this doc) they'd be debuggable when something went wrong. p21: SBD - I'd say that the netservices command will have to be retained until all configuration changes required by that command (aside from enable and disable) can be effected by a svcadm refresh. p23: Virtual Consoles - A service to create instances of system/console? If there's an admin interface to create new instances (and a sensible set of defaults), I'm not sure why a separate service to create them is a better design choice. p26: Precedence Levels - "References to conditions which do not exist will be evaluated as false." Do you think you'll end up needing optional conditions, for the same sort of reasons as we needed optional dependencies? p28: High-level Interfaces - I'm not sure the re-appearance of a deleted service on upgrade is desirable, even in the name of backwards compatibility. p28: Incompatibilities - The "naive client" term is undefined. - "who's" should be "whose". p29: Profile Verification - The "not need to be known by the system" comment confused me for a moment. I think you mean system-provided, but it may be helpful to clarify whether the verification profile must be available in the repository or whether a filesystem target will be sufficient for verification. p30: Committed Profiels - State the specific objective of the local_services profile: no advertized or open network ports. p31,32: Install - I think I agree with the "maybe we shouldn't" note. - I'm not at all convinced that we should start recommending creating the base manifests with the service enabled. Delivering them as disabled is not a workaround, it's a design decision. It allows maximal administrative (and distributor) control over what services are enabled, without being forced to make sure they've changed every manifest when a new service appears. Instead, they can use the base manifests, and a profile that only enables what they want. Otherwise, they'll be forced to re-do their main profile every time we add a new service, rather than just not using our profiles and delivering a few enables in a profile of their own. p33: Metadata - Same comment as above about services enabled on creation. The current ARC policy defines which services must be enabled. You're redefining as "important" with no criteria as to how to evaluate which services are important enough to get enabled in their manifest. p35: Upgrade - I'd explicitly note that upgrades of customizations within SMF can usually be avoided by defining intent-based configuration in SMF rather than exposing implementation details as properties. p36: Patching - Um, I'm not sure this is at all tenable. p37,38: Open Issues (I'd like to go through all of these, but won't delay my review to have written up answers. Here's what I've got so far.) - Removal of service package: Profiles with included deleted change manifests should continue to have their other contents work. May need a way to mark any missing pieces. Properties in the local profile should be maintained. - Temporary disable of new services: Let the service start when it is installed. Expect that runtime addition is the normal, not abnormal case. (Which is true for non-OS-delivered services.) - Using well-known profiles for verification: Suggest that you consider multiple settings for the same value in a profile an error. Misc comments: - Please reserve part of the profile namespace for OpenSolaris use in the future. - I'm not sure how you plan to handle multiply defined profiles. - Service change manifest naming conventions within profiles? liane -- Liane Praza, Solaris Kernel Development liane.praza at sun.com - http://blogs.sun.com/lianep