Quoth Liane Praza on Fri, Jun 15, 2007 at 11:12:49AM -0700:
> 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 .
...
> 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.
Intriguing thought, but if I understand you correctly, I believe
in-progress-ness is an independent dimension of configuration. Complete
vs customization (which is what I presume you mean) is a quality of the
intended configuration; either could be in-progress. As such, I think
in-progress-ness would deserve a separate piece of metadata. Though
since I'm planning on allowing profile-level transactions, I don't think
it's necessary.
In general, whether completeness should allow more values than just on
or off is essentially a question of whether there are other values along
the complete/customization axis. I can't think of any.
Besides, if we did want to change it to an enumeration, as long as the
flag is accessed through functions and not data structures, I think
backwards compatability shouldn't be difficult to maintain.
> 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.
True, I should explain that.
> Using services to represent conditions could also
> make developer-delivered conditions available in Phase 1.
I don't think so, any more than I'm already planning. Please accept my
apologies if this wasn't clear, but the only part that won't be
available initially is delivering a condition that only needs to be
evaluated once without delivering a service. If a developer is willing
to deliver a service to evaluate his condition, then he will be able to
do that right away. NWAM will be an example of this: it will create
conditions and then maintain their values.
> The main place Conditions shine is if there's configuration beyond
> whether a service should run that needs to be Conditional.
Yes, and I believe that's central to NWAM's requirements. How do you
propose that we support NWAM without conditions? Should profiles be
allowed to depend on services?
> 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.
Before we send the jury out, let's flesh out your proposal. If
a developer wants the default policy for his service to be enabled when
condition C is true, and disabled otherwise, but it would be legitimate
for the administrator to enable the service if C is not true (say,
network/ssh is only enabled when there's a network, but could be enabled
to serve nonglobal zones) then I think you're proposing that the
developer deliver a service which represents C and then annotates the
service with a dependency on C. If C need only be evaluated once, then
it seems easy to employ today's "transient" service model, so presumably
C should be delivered enabled, and its start method would evaluate the
condition, and either succeed if it's true or fail if it's false.
Except the latter would cause the service to enter the maintenance
state, which I presume we want to avoid, so either the start method
should temporarily disable the service (potentially with
SMF_EXIT_DISABLE), or perhaps we allow the service to set its state to
"degraded". What if the administrator accidentally disables this
service? Couldn't that lead to the state mismatching the condition it
represents? Should we just blame the administrator for that? Should
svc.startd be taught not to disable condition services during milestone
operations? If the condition can change on-the-fly, should the
developer deliver another service which manipulates the state of the
condition service? Or should we introduce a new service model which
allows a process to run but modulate its state to reflect the condition
value?
Now if the administrator wanted to override the developer's policy and
enable the service when C is not true, wouldn't he have to do this by
deleting the dependency? With conditions, a "svcadm enable" should
suffice. If the administrator wanted to set a policy based on another
condition, he'd have to delete the dependency and create new ones,
right? Wouldn't we also have to introduce new dependency attributes to
allow the administrator to combine conditions in more sophisticated ways
like he could do with predicates?
> 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.
I believe that's what the text says, so I hope one of us isn't confused.
> 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.
This is based on the assumption that the number of virtual consoles is
a property of the kernel which cannot be changed dynamically. (Not to
be confused with the number of ttymon's or X sessions run on those
consoles.) And also that the number may vary between boots, as might
appear to happen if the administrator were to assign virtual consoles to
nonglobal zones. If in fact virtual consoles can be created by the
administrator, then indeed it would be better for that tool to keep the
repository synchronized with the kernel, unless perhaps that tool could
modify an unbooted system.
> 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?
No. But I'm not sure I understand you. I can't fathom a condition
itself being optional, and the only behavior I can think of for an
optional condition reference which is different from what I've described
would be one where the condition is evaluated as true if it doesn't
exist. That behavior should be achievable by negating the condition
value and switching the profile value with the default value.
> 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.
I agree. We refined our thoughts on deletion since that text was
written, so it'll be changed in the next version.
> p28: Incompatibilities
>
> - The "naive client" term is undefined.
You don't think
All clients of today's repository are ``naive'' and
non-administrative clients are expected to remain that way.
on page 17 suffices?
> - "who's" should be "whose".
Ok.
> 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.
I think we meant that the administrator could create his own target in
the filesystem. I'll clarify that text.
> p30: Committed Profiels
>
> - State the specific objective of the local_services profile:
> no advertized or open network ports.
You don't think "Also keeps those services from accepting external
network connections, if necessary." suffices?
> p31,32: Install
>
> - I think I agree with the "maybe we shouldn't" note.
So you think it's ok for a service to be started as part of a pkgadd?
That would be problematic in our current split-usr/root package
convention, wouldn't it?
> - 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.
You're correct that according to the proposal the only way for profile
authors to disable services we have enabled by default is by listing
them explicitly, which will probably lower the profile's stability. But
I don't think the best way to address this is by making all services
disabled by default. I think it will be far more common (some would say
"the 80% case") for profile authors to want to use some minimal level of
functionality as a baseline. Now if the only choice for this minimial
service level were generic_limited_net, I would agree with you that
everything-disabled is better, since it's likely that authors would just
include generic_limited_net and then disable ssh, dtlogin, and whatever
other default local applications it enables. But I think better than
either of those alternatives is generic_limited_net minus secure network
services and local applications -- what I originally wanted to put into
a "system_services" profile. For the uncommon case where an author does
in fact want to start from an everything-disabled baseline, we can
provide some sort of disable_system_services profile, and require
service authors who deliver their service as enabled to also deliver
into it.
> 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.
I agree that the imprecision of "important" is annoying, but I don't
think it's beyond the capability of PSARC to interpret. How do you
think the absence of criteria would be detrimental to the product?
Isn't the judgement pretty close to the judgement for whether init
scripts should have been delivered into rcS.d or rc2.d? Without this
criterion, I'm afraid that profile authors will have to re-evaluate
their profiles whenever we deliver a new service which might be
important for minimal functionality.
> 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.
Isn't that statement dependent on conceptual feature changes being less
frequent than encoding changes?
> p36: Patching
>
> - Um, I'm not sure this is at all tenable.
Do you mean that our current patching technology doesn't allow
developers to fail a patch application based on system status?
> p37,38: Open Issues
...
> - 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.
I agree.
> - 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.)
Discussed above, though I don't understand how my proposal treated
runtime addition as the abnormal case.
> - Using well-known profiles for verification: Suggest that you
> consider multiple settings for the same value in a profile an error.
Do you mean that there should be a way for the user to inquire whether
this has happened, or do you envision something more proactive?
> Misc comments:
>
> - Please reserve part of the profile namespace for OpenSolaris
> use in the future.
I'm thinking of allowing a stock ticker or reverse-domain-name prefix.
I may even require it.
> - I'm not sure how you plan to handle multiply defined profiles.
What do you mean?
> - Service change manifest naming conventions within profiles?
Those are interfaces, which will be treated in the next installment.
But I think the convention will be for those files to bear the name of
the package which delivers them.
David
