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

Reply via email to