[install-discuss] Caiman Architecture document posted for review

[Alan DuBoff]

There's been a lot of good comments, and I looked through the document and 
wanted to comment on a couple things myself.

Packaging
---------
Early on in the doc it states:

"While packaging and patching are important in delivering Solaris it is 
considered a separable problem area."

While a seperate issue in itself, there's a lot of seperation between ITUs, 
Packages, Patches, and Updates. Software is software is software to me, the 
installer boots and gets configured, transfers the packages needed, installs, 
then configures them (we fail horribly on configuring software today). When I 
install postgres, mysql, or any piece of software, have some type of setup 
done so it doesn't toss all of that burden on the admin/user. The key to ITUs 
is to have them available at install time, and aside from NIC drivers, all 
others can be gotten over the net after the network has been configured 
(early in install is much better than later as we do today of course).

I actually believe that packaging and patching is a very important aspect, to 
work with in the long run, and I wonder why there is a difference between 
package installation, patches, upgrades, or even management changes done 
through package distribution. It is all about the software on the system.

Push vs. Pull
-------------
This has been a religous debate amongst those who have been involved with 
updating and installation of software. How does one view it? Some folks 
insist that pulling is the traditional and defacto way that the management of 
such software should be handled. There are good reasons for pushing as well, 
and in terms of management there are some great things that can be done to a 
large group of servers being managed by an admin. Even in the case where the 
same tool is being used, rsync as an example, there's a difference in the way 
you view things if you were pushing or pulling, depending on the source of 
your data. While a minor or distracting point to some, being able to push and 
pull is very useful.

Security
--------
I don't see anything about security. I really hope this is a piece that will 
be included, since having a secure install network to install from is very 
important in today's climate. I'd like to see a seperate Security Network 
that could be used to query package authentication, so that packages could be 
gotten from anywhere, and safely verified. Solaris has much of the capability 
today in terms of knowing which files have been modified on the system or 
not, but doesn't use it too effectively. All of install, update, and patching 
should be secure in the future, so that it can be done safely over the 
network.

Dynamic Repository
------------------
For me, sources are sources, wether a package comes from xyz server, my local 
hard disk, a CD/DVD, nfs mount, or *preferably* over the network, all of 
these packages should be available as a whole. There could be advantages to 
putting encrypted software in a specific geo, to make it easier to get. The 
open source communities do this for the most part, and we should also to 
remove some of the burden placed on Sun as a corporation. Ultimately, Sun is 
a user of OpenSolaris just like any other distribution would be. Knowing 
these packages are trusted and secure when installed to my system is very 
important in this regard.

Simplification
--------------
Some of the flow diagrams are complex to look at, 1.1.1 as an example could be 
simplified and/or arranged to remove some of that complexity, at least to me.

The left column of services could be grouped as a whole and labeled something 
like initialization/setup/similar, the the transfer service taking action 
from there. My target could be local or remote, in the long run, getting back 
to push vs. pull which I mention above, but let's just focus on pulling data 
to a local system first I guess.

Logging/Meta Data/Patch services seem like Admin type services for the 
install.

I'm not trying to nitpick, I'm not great at drawings, and someone put quite a 
bit of effort in the doc already, I'm just trying to point out that this 
complexity will confuse management also, IMO.

Drawing 2.1.3 might be a better view of how I was thinking 1.1.1 could be 
simplified, and the left most Software Selection is like the 
boot/config/setup I mention above, and the right most software selection is 
really configuration/customization.

These would both be clearer to me if the GUI was on top of the Orchestrator, 
since in theory it is.

Database
--------
If there is any way at all possible to use SQL-Light, Berkeley DB, or similar 
light database client to offer an option over the "contents" file as we know 
it today, that would be swell. I'm ok with the contents file and amazed it 
doesn't get more corrupt on more systems, than it has. This causes us a lot 
of time during package installation I would guess, but not certain.

Process Control
---------------
I like the idea of how the orchestrator handles things, and not sure how the 
services were intended to be distributed, in the sense of processes being 
created, running, and ending opposed to created, running, and using IPC to 
talk between them in more of a static state with queues. The orchestrator 
might work well having a few running subordinates, which it would talk to 
with IPC, but have those subordinates manage the background proccesing of 
their own respective processes that will end after completed, if that makes 
sense (hey it does to me;-). Maybe that could be 
Setup-Boot-Config/Transfer/Target/Customization agents running, that would 
distribute the other various services, if that makes sense. 

Anyway, just some food for thought...

-- 

Alan DuBoff - Solaris x86 Engineering - IHV/OEM Group
Advocate of Insourcing at Sun, hire people that care about our company!