Mike Gerdts wrote: > On Mon, Jun 22, 2009 at 11:17 AM, Keith Mitchell<Keith.Mitchell at sun.com> > wrote: > >> Mike Gerdts wrote: >> >>> On Sat, Jun 20, 2009 at 2:07 AM, Sundar >>> Yamunachari<sundar.yamunachari at sun.com> wrote: >>> >>> >>>> Hi, >>>> >>>> The updated functional specifications for AI transport mechanism - >>>> version >>>> 2 is available at >>>> >>>> http://wikis.sun.com/display/OSOLInstall/AI+Transport+Mechanism+v2+-+Functional+Specification >>>> . The major changes from version 1 are >>>> >>>> 1. Added a use case for archive based installation >>>> 2. Added a use case for null transport >>>> 3. Added more information in the P2P use case >>>> 4. Added a documentation about web server cache and various environment >>>> >>>> (http://www.opensolaris.org/os/project/caiman/auto_install/ai_design/web_server_cache.txt) >>>> 5. Combined use case 1 and 2 (solaris.zlib) and removed references to the >>>> zlib files. >>>> 6. Changed title and other minor edits. >>>> >>>> Please review and provide feedback. >>>> >>>> >>> My main complaint with the architecture is that it makes DHCP a >>> required component, even with wanboot. I would much prefer to see >>> that DHCP is not used with wanboot (just as is the case with S10 and >>> earlier) and that there is a very small grub-ish iso available that >>> can act similar to wanboot for x86. Such an iso should be OS-release >>> agnostic, just as the wanboot code in OBP is OS-release agnostic. >>> >>> In many environments, DHCP is controlled by a team that has little to >>> no interest in helping to support server installations (e.g. it is >>> controlled by the team that worries about Windows laptops). There are >>> sometimes specific policies against allowing DHCP (particularly for >>> DMZ's and other semi- or un-trusted networks) that do not exist for >>> HTTP and/or HTTPS. This will serve as an inhibitor to adoption of >>> OpenSolaris in such environments. >>> >>> >>> >> Hi Mike, >> >> While I agree with you and Dave Miner that requiring DHCP is not a desired >> situation, that specific issue is, I believe, outside the scope of this >> functional specification. If there are sections of that document that seem >> to imply otherwise, that will need to be fixed. Is there a specific section >> of this document that is causing concern? >> >> Thanks, >> Keith >> >> > > Section 2.a.i was the key area, but I guess the language does leave > enough room for some other mechanism to exist. > Yes. The point we're making here is that, in order to have transport from point A to point B, there has to be a path from A to B. We can try and re-word it to be more clear. > http://www.opensolaris.org/os/project/caiman/auto_install/ai_design/transport_data_diagram.pdf > seems to indicate that DHCP is a required component for x86 and SPARC. > There is no recognition that all of the network configuration can be > performed for wanboot via network-boot-arguments. I suggest adding a > note to the table on page 3 to the effect of "DHCP is not required on > a SPARC client that uses wanboot and has specified network parameters > via network-boot-arguments or interactive prompts." > > As mentioned in section 1.a, the scope of the enhancements and improvements for this project are limited to those files that are, at present, handled by Apache & CherryPy and transferred via HTTP (items listed as being under "Transport Control?" in transport_data_diagram.pdf). As Dave mentioned, the requirement on DHCP is a bug. I will make a note to clarify those points (in particular in the areas of the functional spec that link to that diagram). In particular, the functional spec does seem to imply that the DHCP issue "cannot be changed" when that's not the case.
Side note: I will also try and fix some of the numbering issues. We had some issues with inconsistent formatting since we have had several of us editing the page. -Keith
