Michael Ramchand wrote: ... > To try and be able to code and capture every single one of these within > the manifest is folly, kind of like trying to count all the grains of > sand on a beach. The response when we provide lists of "things" that we > do seems to simply get added to the infinite list of "things AI could do > in the manifest". You need to accept that there will ALWAYS be something > that you/we have not thought of, and we MUST have a mechanism/hook to be > able to override if required. >
Sigh. Collecting requirements does not imply that the solution will be "add something to the manifest"; you've supposed that solution when it hasn't been presented. Further, there are already substantial override hooks: providing site-specific IPS packages and SMF services for one, building custom automated installation images using the Distro Constructor for another. I will not assert that this represents a complete response to all scenarios, but the latter in particular provides far more capability than was ever supported in the old product. I'm sure its somewhat disconcerting to all of the old hands that a large portion of the requirements and solution process is happening so publicly, and that releases of a product are made without all of the expressed requirements satisfied, but that's how we're doing things now. > There's a balance between providing for the masses by presenting a > limited number of best practice options and reducing the complexity of > the install, which I think we MUST do, and enabling the expert user to > configure down to the tiniest detail. Presenting too much functionality > in the manifest may alienate some users. > I see dissonance in the above, but since we haven't proposed any solutions which present any more in the manifest than the legacy technologies, I think we'll leave that argument for the appropriate time. > I also agree with Peter Tribble, yes, most of the underlying Jumpstart > code is old and difficult to maintain (well, it's not all that bad > really), but we've come a long way, and Jumpstart is well understood by > many of our customers, using protocols that are widely used by our > customers. > Which protocols are you objecting to here? AI is using a subset of the protocols previously used, having dispensed with the Paleolithic RARP/Bootparams combination (which you seem to agree with subsequently). We're experimenting with mDNS, and with some additional HTTP usage; both are subject to change as the design evolves. However, we're not going back to a Jumpstart-language profile, though we may choose to provide some compatibility as a transitional aid. An architectural requirement is to share this language for our construction process, which was utterly disconnected in the old system. The remaining things you've described below generally seem to break down as: - Provide deployment of non-IPS-packaged software - Provide generalized system configuration. Would that be a fair summary? Dave > So here's a novel idea, why don't we maintain the Jumpstart "API" at > some level. Lets rewrite setup_install_server, and add_install_client > and make them smarter. Let's remove bootp and standardise on dhcp > builds. Let's remove the need for those special SUNW symbols for the > SPARC builds like something more menu.lst.MACADDRESS like for SPARC). > Let's remove the need for sysidcfg by incorporating it into the menu.lst > thing somehow. Let's extend the profile so that we can do more within > it. Let's simplify the rules file so that we only have one rule, but > leverage a better "begin" scripts so that we can do derived profiles by > default. (A good begin script obviates the needs for a rules file) > > So from a user perspective, there's no new protocols, there's a couple > of functionality extensions. Under the covers its all nice bright shiny > new code, but the burden of learning a new tasks is removed. > > Finally: We seem to be focussing AI on purely the O/S install bit. The > funny thing is that the O/S install bit in Jumpstart is absolutely fine. > Customers don't have a problem with that bit. The HARD part about > Jumpstart is the bit AFTER the O/S is installed, when people want to > deploy useful things like applications and other esoteric configuration > parameters. You can't replace Jumpstart without providing the > postinstall functionality, which is where all the work that the > customers consider to be valuable gets done. There's 3 levels to Jumpstart: > > 1: Doing a net install, and running the interactive Solaris Installer. > (add_install_client, provide mac address, IP address) > > 2: Non-interactive net-install: (add_install_client, provide mac > address, IP address, rule pointing to profile, sysidcfg): Solaris > installs unattended. > > 3: Non-interactive net-install: (add_install_client, provide mac, ip, > rule pointing to profile and finish script, sysidcfg): Solaris installs > unattended, plus installs all the cool and interesting stuff that > customers actually want to run. > > Obviously level 1 and level 2 are just building blocks to 3, but it > seems that all the focus on AI is on Level 2, while the customer value > actually derives from 3. If you look at JET, the SUNWjet package deals > with level 2, all the other modules are the things that do all the level > 3 stuff. > >
