[email protected] wrote:
On Fri, Feb 27, 2009 at 01:55:22PM -0800, Bart Smaalders wrote:
>> ...
I'm not exactly sure why this is needed, since the commands invoked as
side effects run w/ the same priv. level as the components that are
being run from the image.... this seems to propose a rich service-based
architecture for user-images, the details of which aren't disclosed here.
This is part of my objection. The need for actuators in user images
seems to imply that a cross-platform service library should be
constructed.
That's not what I'm implying. The need for actuators in user images
simply implies the need to have package installation trigger some
code execution -- that's the same need (or at least one of the
needs) the SMF based implementation satisfies.
Maybe my modeling of the UserImageActuator attributes after the
SMF actuator attributes is confusing. That's certainly something
that can be changed.
> However, the approach the proposal takes is to allow
arbitrary code to execute as a side effect of the installation. This
violates our maxim against no scripting / no arbitrary code.
One of the design specifications listed for UserImageActuators states:
o Any failure of a UserImageAcutator hook must not cause an
imageplan evaluation to fail
Unforuntately, this is unenforceable if arbitrary code is executing.
But isn't this true with the SMF implementation as well? My package
can install an SMF service and restart it and now that arbitrary
code (the SMF service) could misbehave.
It would make more sense to enhance the actions that are available for
user images. If service framework is really needed -- what problem are
we trying to solve anyway? -- it might make sense to extend actuators to
work with another service management framework. Let's not create another
mechanism to invoke arbitrary methods. We don't want non-deterministic
behavior in the install.
I'm not proposing the need for a service framework for user images.
When folks hollered that they needed "package scripts" one
of the responses was: no you don't, you can do that with actuators.
The current SMF Actuator implementation provides the ability for
a package installation (or removal or update) to trigger code to be
executed. The goal of UserImageActuator is to provide that capability
for user images as well -- while still maintaining the integrity of
the package installation (and with no impact to system images).
Joe
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss