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. 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. 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. 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 am thinking if those macros are needed or if we could avoid creating them. Looking at the examples, they seem to be unused. 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. 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
