On 3/23/06, Dave Miner <Dave.Miner at sun.com> wrote: > I would appreciate review comments by April 14. I encourage posting > comments to this list, but private comments are of course equally > acceptable.
I'm *so* glad to see that this is an area of focus. My comments on the document and installation related tasks follow. Page 6, Bullet 2, sub-item 2: SUNWCXall no longer does the trick... when SUNWCXall is installed on a sun4u box (15k domain) the sun4v platform support is not added. This implies that in addition to my 15k domain used primarily for image development (that ain't cheap), I now need to have a T1000 or T2000 sitting around for the same purpose. In a globally distributed jumpstart environment, I now need to distribute three ~2 GB flash archives to get x86-64, sun4u, and sun4v support. Page 8 - Live Upgrade is also hampered by the following in my environment: 1) It uses a version of cpio which does not support sparse files. This causes files like /var/adm/lastlog to balloon in size when large UID's (100,000,000 - 999,999,999) are used. Similar issues likely exist if a quotas file happens to be in a partition used for live upgrade. 2) It has spotty support for upgrading to metadevices. 3) It sometimes requires applying patches and new packages to a running system Page 11 - DHCP, PXE, etc. In Update 1, vendor DHCP options for x86 became unsupported in favor of maintaining those in menu.lst files. Note that there was no EOF announcement to help customers prepare for this change and that all of the required functionality is still in the miniroot that is TFTP'd. Turning /sbin/dhcpinfo into a wrapper that does "if [ some_condition] ; then ifconfig bge0 dhcp primary ; fi ; exec /sbin/dhcpinfo.orig" brings this feature back. This change seems completely unnecessary and only serves to fragement x86 and SPARC jumpstart environments. Did I mention there was no EOF announcement and only one off-handed mention in the release notes? Page 11 - JASS is worth mentioning as well. Page 12 - More DHCP... - Documentation on how to set up Sun's DHCP server is overly complex and suggests lots of changes for every machine being installed. It is possible to architect a jumpstart environment using Sun's DHCP server such that a single pntadm command can be used to switch between macros that point at distinct jumpstart releases. It is really hard to find a reference to anyone other than Sun using Sun's DHCP server for jumpstart. Perhaps Sun should consider migrating to ISC dhcpd where there is much more mindshare (and support for vendor options that exceed 255 bytes). setup_install_server and friends assume that a Sun box is going to be the host for the boot media and refuses to work if it is NFS mounted from elsewhere. In environments that NAS appliances are leveraged for all other NFS serving, it is quite likely that the NAS appliance is the "right place" for the miniroot and other jumpstart data. When debugging jumpstart installations, it is common to spend more time waiting for the system to reset than it does to figure out that the jumpstart is just going to bomb out again. I saved a lot of time when I learned about using two or more of the following commands: rm /tmp/.jumpstart ifconfig bge0 dhcp renew suninstall Section 2.2.6 - Installing from flash archives whacks all sysidcfg information. In a disaster recovery scenario, you likely don't want that to happen. Integration with flash archives and a custom netbackup agent would be nice... Section 4.1.8 - Local caching of Sun software distribution sites should be viable. Prepopulating with up to date packages, patches, product stacks, etc. should be possible so as to allow customers to be "self sufficient" and minimize the risk of WAN outages, Sun outages, etc. on scheduled maintenance activities. Optimization of network performance is sometimes a matter of optimizing the size of installation media. If something like flash archives continues to exist, they should use a better compression tool than compress(1). Other ramblings... - Options used for debugging the installation process should be part of the public interface. Custom installation modules should be able to hook into the debugging framework through a public interface. - Installation DVD should have a slimmed down version (optimize download/burn time) that is usable as "rescue" media. It should not need to connect to an external system to become usable in its most basic form. ISV's should be encouraged to provide customized versions of this for recovery options. Example customized versions may include support for importing VxVM disk groups and mounting VxFS file systems, bare metal restore, etc. - In the spirit of "sharing" there should be a mechanism that makes it easy for people to publish software stacks without having to provide the installation media (bandwidth constraints, legal limitations on redistribution, etc.). For example, pretend that someone interest in MythTV figured out what the magic minimal bits were to make it work on a particular release of Solaris, with a particular driver release that is available from the IHV, and some other stuff from SourceForge. Assuming each of those sites provided the appropriate web service for delivering software via Caiman, I should be able to provide an xml file on my own web site that ties all of these things together into the perfect PVR. - One thing that concerns me about creating N ZFS snapshots for N zones is that they will start out using about X GB, where X is the size of the source of the source file system. Over time, however, the zones will get patched independently but will end up with the same set of patches but will approach N*X in size. There should be some way to reconverge the various bits on disk that contain the same data, therefore returning the size back to X. This is likely more of a ZFS problem than an installer problem. Again, I'm very glad to see that this is getting attention. I like the overall approach and think it is on the right path. Mike -- Mike Gerdts http://mgerdts.blogspot.com/
