Hi Peter, Thank you for the review.
> On Thu, Jun 12, 2008 at 10:31 PM, Sarah Jelinek <Sarah.Jelinek at sun.com> > wrote: > >> Located at: >> >> http://www.opensolaris.org/os/project/caiman/auto_install/AI_Reqs_Final/ >> >> Are an updated set of AI project requirements. >> > > 2.3 Why provide a gui? What users want is a way to manipulate > the profiles using their own tools. > Users can use their own tools to manipulate the profiles. The GUI is simply our way of providing profile creation and modification. The profiles are not secret or hidden and the syntax of these will be public. > 2.9 What sort of minimal installation? Everyone will have different ideas as > to what this means - what's important is that the scheme is flexible and > powerful enough to meet all customization requirements. > Minimal system configuration, not minimal installation. So, we will provide at least what the OpenSolaris installer provides in terms of system configuration capability. > 3.1 Not a specific release, but what range of releases? S10? S8? 2.6? > > At this point I don't know. Depends on how we setup the clients to boot the AI images. I am considering Multicast DNS, which is very different from the dhcp setup we use today. But, regardless the basic scenarios I am considering are: -Old install server system, that is installed with < OpenSolaris 05.2008 with new OpenSolaris images to serve. This one could be problematic depending on the features we need to setup install clients. If the new features we rely on are not on the old install server, what do we do? -New install server system, >= OpenSolaris 05.2008, hosting old install images. This one isn't one I worry to much about at this time. This scenario means that if we don't have the necessary features on OpenSolaris the old image is likely not able to be served. I don't think this case is much of an issue really, since at this point in time OpenSolaris generally has the features installed to serve old images. > 3.2 What services are required on the install server? It's no use > configuring them > if they're not installed. > > Don't know at this time. As I noted above we are considering mDNS for client/server communication. And you are right, if the required services are not there, we won't configure them, we will likely fail saying that the release serving the image doesn't have the necessary features. > 3.3 What sort of recovery image? Install back to initial state or current > state, > capturing customizations or not? > > I think initially we will only capture the initial installation state. Capturing customizations is more difficult. Not impossible but does require some tracking or ability to get the customizations. In particular since at this point in time we can have both IPS and SVR54 pkgs installed. Not to mention features installed via tar balls, etc.. > 4.3 What configurations can be upgraded from? > > ZFS->ZFS at this point in time. Unless the snap upgrade feature provides a way to go from UFS->ZFS. And, OpenSolaris->OpenSolaris at this time as well. > 4.5 Isn't this 3.3 again? > > Yes, I will remove. > 4.6, 5.2 Why does the installer manage virtual environments? Surely the > virtual environments should manage installation? > > What I was thinking was that we want to be able to install a system, or a virtual environment from the beginning. That is we want the user to be able to say: -Create a VBox virtual system -Install OpenSolaris in this VBox virtual system. The idea is that we want the users to be able to start with a clean system, and install everything and configure it start to finish. The way the users have to specify stuff one time, not boot the system, install VM ware of their choice, configure it, and then install it with a version of OpenSolaris. Where this becomes problematic is a non-Solaris client. Say they already have Windows installed and they want to install and configure VBox with OpenSolaris. But, for Solaris clients this wouldn't be that hard for us to do. Much like the pre-configured VM images we are planning to provide with Caiman. > 7.1 Secure against what? > > Secure against malicious attacks, untrusted users on a WAN for example. WAN provides secure installation now via https. > 8.1.2 NFS is a must - if it's available, that's the one to use. (You need > http to handle the WAN case.) > > I think we can use NFS if it is available. but, I want to keep the architectures for both WAN and LAN installation and boot as similar as possible. http allows us to do this. WAN does use http and there is no reason, other than a small matter of grub not supporting http or NFS, that we cannot use http for network support. If the system has a small amount of memory available then likely NFS is the way to go. > 8.2 Would be nice to install from local partition or downloaded iso > image. (Clearly > this involves playing some games, as you can't have the media oon > something that's > used directly to install to.) > > Well.. that might fit in to the live installation scenario. Have to think on this a bit. > 10.1 Must be *much* faster than LiveCD. Must be significantly faster than > current jumpstart too. Need to set some realistic targets. We know how long it > should take - 5 minutes would be a reasonable target. > > Fair points. I don't have specific performance data at this time, so I am hedging my bets. I agree it must be faster than current jumpstart and it will be and already is mostly. To do some performance testing I moved the IPS repo to my install server and ran the AI installer it went way faster than the current image does. The longest part of this was the manual Gnome postrun stuff we have to run. This took 10 minutes. The install, including IPS took only about 5 minutes. I think its safe to say we will be faster than we currently have. > 10.2 Need to be much more aggressive here. I don't see any reason why 256M > shouldn't be the target. I might accept 384. The bulk of available systems out > there are still 512M. Sun are still selling 512M machines. And you need to > allow > some room for graphics stealing and headroom. And then there's virtualization, > so you want the footprint as low as possible to cram as many VMs onto a server > as you can. > > we will be aggressive on the memory requirement. I think that we might reach 384, based on my recent testing with IPS on the server, or somewhere on the network. but, 512M is what we will commit to for now. Thanks again for your comments. sarah
