On 01/ 7/10 09:11 AM, Jan Damborsky wrote: > Hi Dave, > > the overall document looks pretty good, I have just > couple of questions/comments - please see below. > > Thank you, > Jan > > > image provisioning > ------------------ > > If I understand correctly, separate AI image has to be provisioned > for each install service to be created. I am thinking if this might > be considered as a limitation by some users. > > As SXCE is to EOLed, couple of discussions happened with > internal developers about switching to OpenSolaris and using AI. Some > people asked about possibility to provision separate machine serving AI > images > and IPS repo while they would just provision install services on local > machines (e.g. on the same subnet or site as test machines) and just > associate > install service with URL of remote AI image. > > The reasoning behind this scenario is that AI images don't require > customization (thus could be shared by all install services serving > the same build) and that process of provisioning AI image has visible cost > (space, time). > > I am not sure if that could be accomplished by existing implementation > of technologies AI consumes (it seems that at least wanboot would need to be > enhanced to allow this), but I am wondering if this is something we could > consider. >
Some of this thinking really comes from old experience with the limitations of RARP and the need to break up the boot server from the install server in order to scale. Once you go to a DHCP-based design (or a client-driven design such as wanboot or bootable AI media) that doesn't seem like an especially valid need. If you want to share an AI service, you do so via DHCP or providing the manifest to the booted system. Overall, I don't think this represents a significant limitation. > gPXE > ---- > > That leads me to another point - the proposal currently operates with > technologies they are available and proposes to leverage them if needed. > > I am thinking if for x86 case we should take a look if gPXE could be > better alternative to pxegrub for booting the kernel and boot archive. > That would allow us to use other protocols than TFTP (namely HTTP). > > I am not sure what effort would be actually involved (it seems > it might not be trivial to make things work), just wanted to bring > that point up. > I'd like to have a discussion with the boot team around that. The upcoming GRUB 2 transition may or may not be planning to affect this. > > image validation > ---------------- > > This is something not mentioned in document and perhaps not applicable to > the images deployed by pkg(5), but since it is mentioned that support > for ISO images will not be discontinued, I think that those should be > validated in order to avoid issues reported by bugs 4712/5393. > Agreed. > > DHCP - install service macros > ----------------------------- > > Document proposes to create DHCP service specific macros (with name > incorporating service name) for each service to be created: > > ... > - The DHCP macro names generated for each AI service will use a prefix > of "AI_" rather than the "dhcp_macro_" prefix that is currently prepended. > ... > > Since the intent is to make AI as less dependent on DHCP as possible > and limit things AI need to configure with respect to DHCP, I'd like to *allow* it to be limited, but also to allow DHCP to be leveraged where desired. > I am thinking if those macros are needed or if we could avoid > creating them. Looking at the examples, they seem to be unused. > A deficiency in the examples that I need to correct. The idea is to allow inclusion of these macros to configure individual clients to specific, non-default services. So for client with MAC addr of 0:14:4f:9b:84:e0 you might have a macro that says: 0100144F9B84E0 Macro :Include=AI_osol-dev-117-i386: > I think that when first service is created (or when client > is associated with particular install service), client > class DHCP macro (or client ID DHCP macro) could be created and > then all subsequent client/service manipulation (e.g. changing > default service or associating client with other service) could > be done within tftp root directory (e.g. by creating/removing > symlinks as needed). It would be similar approach to the > one currently used for Sparc. > I'll think about this some more, but see notes above. Thanks for the review. Dave > > > On 12/16/09 12:51 AM, Dave Miner wrote: >> Caimaniacs, >> >> I've posted a draft proposal for design changes in AI to simplify and >> enhance the image management. Comments are requested by January 8. >> Spec is at: >> >> http://hub.opensolaris.org/bin/view/Project+caiman/AI+Image+Management >> >> If you'd like a printable copy, use the Print options on the xwiki >> site. Exporting as PDF provides a fairly usable print copy. >> >> Thanks, >> Dave >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
