[caiman-discuss] AI Design begin/finish scripts

Dave Miner dminer at opensolaris.org
Mon Jul 7 10:46:30 PDT 2008


I'm not going to try to respond point-by-point to the discussion that's 
occurred over the last 5 days.  There are several points that I'll make:

1.  Bart summarized nicely how I think this can and should work for the 
common case.  The issues noted around profile generation and matching 
deficiencies in Jumpstart are something that needs to be addressed 
generally, not pushed onto customers.  And since this is an open-source 
development, I hope that we can enlist community assistance in 
developing that aspect to the level of functionality that's truly 
needed.  That wasn't an option in the old days.

2.  Much of the argument is that we must continue to supply ad hoc 
scripting mechanisms similar to what we've had in the past, because 
that's our "get out of jail" path.  I must say that I presently reject 
that argument, for the simple reason that we're factoring the problem 
differently.  The "get out of jail" path going forward is to use the 
Distribution Constructor to define your own (likely derivative) 
distribution, build that image, and deploy it.  That can include your 
own packages, which can do whatever you want in the context of your own 
environment.  The support for that distro would continue to be at the 
level of "we'll support our packages, you support yours".  This option 
was not present, nor imagined, when Jumpstart was designed, but is a 
quantum leap in capability without the unsupported voodoo that the old 
blueprints articles for customizing media represented.

3.  Many of our maintenance issues with the installer in Solaris have 
revolved around its general lack of integration with the system 
architecture.  It is extremely desirable from an architecture 
perspective to design the automated installation process as one (or a 
small number) of SMF services which integrate with the rest of the 
system architecture as a fairly simple application, rather than building 
a special execution domain around the system.  Providing uncontrolled 
execution of user-supplied scripts in that context seems problematic 
from my perspective - it creates the very thing we are trying to avoid, 
and likely requires exposing what are properly implementation artifacts 
of the installer as stable interfaces for customers to use.  We may 
eventually need to do so for some reason, but seems unnecessary for the 
initial target product and thus premature to identify as a requirement.

We've got an opportunity to build something much better right now.  I'd 
prefer to start by exploring new ways of solving problems (assuming we 
can state the problems) that are based on the technology we now have and 
are developing, rather than dated assumptions about the system 
architecture and product structure.

Dave



More information about the caiman-discuss mailing list