Hi Dave, I am updating the AI requirements document to reflect the discussion and will send out a revised version of this shortly. In the process of updating the AI req's I am revisiting some of the past emails and making sure things are resolved. or as resolved as we can make them at this point.
A couple of new comments/questions inline... > > I think there's a requirement to control whether automated system > configuration is done at all. I presume part of the data that would > be supplied in the profile is the location of the SMF Enhanced > Profiles to use. > I agree. I am updating the requirements document now to reflect this. Also, as I did more research on SMF it seems to me that SMF visual panels is the utility we would use to do the system configuration, not enhanced profiles. Well.. maybe a combination. In looking at the VP demo I see they are allowing for(at least in the demo) keyboard configuration. But the networking stuff is a part of SMF today, mostly. >> -All configuration data that cannot be determined must >> be specified in SMF extended profile. > > Perhaps "may" rather than "must"? Do we want to allow for the > possibility of a "semi-automated" installation? Later no in the > "Types" section you seem to say we will. > Yes, we allow for semi-automated installation. I have modified the requirements document to clarify this, and to state that we won't require configuration data to be specified. If not specified, on first reboot the system will ask the appropriate questions. I am of course assuming a fair amount with that statement in that VP will do this for us. I have to check with the VP folks to verify this. >> -Minimal system configuration will be allowed via the >> language specification provided for automated installation. > > > > With respect to the last sub-item, is there a need at all to provide > system configuration within this language? Or does that merely point > to the need to extend the realm of items covered by SMF profiles? > Some examples of what you're thinking are probably necessary to sort > this one out. > I think we need to provide some system configuration capability with the language. Then we will utilize the SMF VP capability to actually set the values. I think what you are asking here is For example: -Specification of keyboard layout. For the user to use SMF VP syntax to do this is I suppose ok(which is what I assume you are asking for). I guess it depends on how this specification is designed. Now for things like locale which don't appear to be under the SMF VP scope maybe we need to extend the realm of things covered with SMF profiles. >> Tools: >> -Will provide the necessary tools to setup automated installation >> servers and add clients. -These tools will be backwards >> compatible and not >> tied to a specific release. > > "backwards compatible" to what? > >> -These tools will configure all services necessary to >> complete network installation. >> > > I presume the scope here is "services on a single server", unless > you're proposing a distributed management tool, which I'm unclear > about based on this next point: Yes. single server. > >> -Will provide tools to view existing install servers, configurations >> of those servers and clients associated with each. >> > > Would this include providing functions to distribute/replicate > installation services across some multi-network scope, in the vein of > the getimage tools we use internally? I'd like to, though it may > start hitting conflicts with the ops center products. > From what I know about getimage it uses ftp or http to transfer the images to install servers. It does image verification and does checking to see if a newer version is available based on the initial > >> -Will provide a tool to create a recovery image from the system. >> > > This one is something we had planned to be part of the next phase of > DC. I guess I don't really care which way we look at it, but I have > felt it matches more closely with what DC does than with what I viewed > as the AI scope. I have removed this requirement from the AI spec. I think it does align with DC. Although, the requirement for AI to generate a Profile after > >> -Will provide support for creation of ZFS root pools. >> -Hot Spare support >> -Intent log support > > There are a lot of potential ZFS options we might support configuring > that we don't currently (mirrors, compression, copies, encryption > soon). What's special about these two? > >> -Will provide system upgrade via Snap Upgrade. >> -This is not a live upgrade style of upgrade, it is >> more like a standard upgrade using the Snap Upgrade >> utilities. > > Why? > >> -Will provide the ability to send and receive ZFS snaphosts to >> populate >> a ZFS root pool. > > Why is this in your scope? > >> -Will provide xVM DomU installation and upgrade support. > > Some elaboration on what you're thinking here would be helpful. I'm > not sure why it's in the AI problem space. I am assuming what is in the AI problem space is the ability to specify and create DomU's and then do the installation in to the newly created DomU. I will clarify. > >> -Virtualization platforms such as Parallels, VMware and xVM > > Not sure what this is intended to be, either. How do we provide an > automated installation into VMware, for example? > >> -Will support non-Solaris installation servers. > > Let's be specific about the platforms that we think we should support. I have added specifics to the AI req document. > >> -Will provide secure installation > > This could stand elaboration. Do we mean something exactly the same > as secure Wanboot, something else? I have expanded on this in the AI req document. > >> Protocols >> Network support: >> >> -Will support DHCP, NFS, http, https client/ server protocols. >> > > > You left out tftp, but also should explicitly say PXE. I would > actually make this more specific per platform as to the methodology to > be supported. > I have added this. thanks, sarah *** > >> -Will support creation of non-root datasets within ZFS root pool. > > Is there a reason we need to provide specific support for this rather > than assuming it can be done in the generic post-installation hooks? > >> -Will provide fdisk partitioning support only until full GPT boot >> support is available. > > I'd think we'll need to continue supporting fdisk for quite some time > past that, actually. > >> -ITU and driver detection support will be provided. > > I'm not sure what driver detection would usefully do in an automated > case, got some ideas to share? > >> Performance: >> -Will provide reasonable performance for local and network >> installations. > > I'd think we want to establish some stronger requirements here. > Certainly some of our customers have specific ideas on what > "reasonable" is... > > Dave >
