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!
