On 07/01/09 11:50, Ethan Quach wrote: > > > Susan Sohn wrote: >> Ethan, >> >> Thank you for the comments... >> >> On 06/30/09 00:52, Ethan Quach wrote: >>> Sue, >>> >>> Comments on the AI services functional spec ... >>> >>> >>> 1.4.2.1 >>> >>> Don't know if it really applies here, but it would seem like >>> making an OpenSolaris system run as an S10 Jumpstart server >>> is a preferred scenario for 'coexistence of install servers' over >>> an S10 system running an AI server. AI wouldn't have to be >>> limited by S10 in that case. >> >> As Dave mentioned in a later email, users will likely want to start by >> using >> their existing infrastructure, so I think we should keep S10 on the list. > > Okay, that's a fair point. > >>> 2.7 >>> >>> Do we not plan to continue to store AI service configuration in >>> SMF? 5.4.3 says that SMF could be used on Solaris. >> >> At this point, the intent is to continue using SMF properties to store >> the AI >> service configuration. However, the functional spec doesn't put any >> restrictions >> on the chosen database backend or the database structure. > > The third bullet makes it sounds like it's a given that a conversion > needs to happen.
True enough. Although it's fairly likely that we might need to do some conversion even if we continued to use SMF (possibly different properties, for example). I've reworded it as follows: install services ? information about install services are kept as SMF properties in 2009.06 release. Those would need to converted to the newly designed format if SMF were no longer used. If SMF were used, additions/deletions/modifications to existing properties might be required. Services would need to be registered.... Thanks, Sue >>> 5.3.2 and 5.3.3 >>> >>> The required hand of the DHCP server to define subnet and >>> global scope worries me. The last implementation requirement >>> stated in 5.1.1 says that we should be minimizing interactions >>> and dependencies between AI and DHCP, yet this part of the >>> spec seems to go against that. >>> >>> Is it possible for us to somehow define install service scopes >>> as a non-required or tertiary *attribute* of an install service, >>> rather than baking in scope as in inherent characteristic? My >>> concern is the lack of control we have over DHCP config in the >>> architecture, so depending on it to define characteristics of our >>> services seems unreliable. >> >> Scopes are used to group clients by characteristics to avoid client >> specific >> setup. Since we are using dhcp for now, the scopes we have chosen are >> those >> which are suitable for use with dhcp. However, the design is >> modularized, so >> that we aren't tied to dhcp and if we were to not use dhcp, we could >> group >> clients by other criteria. > > The modularity wasn't so obvious to me in this spec, but yes, > that's what I was after. Thanks. > >>> 5.4.5 - Question - Since wanboot scope definitions are on >>> the AI server, does this mean that for architectures that use >>> wanboot (i.e. Sparc), you can't have the subnet scope >>> configuration on one AI server and the global scope >>> configuration on a different AI server? >> >> It is possible for both sparc and x86 to have one AI server provide >> global scope >> and another AI server provide subnet scope. > > Okay .. > > > thanks, > -ethan > > >> Thanks again, >> Sue >> >>> thanks, >>> -ethan >>> >>> Susan Sohn wrote: >>>> The functional specification for AI Services is posted at: >>>> >>>> http://www.opensolaris.org/os/project/caiman/auto_install/ai_svc_func_spec_v1.pdf >>>> >>>> >>>> >>>> Please review and send feedback to the alias. >>>> >>>> Thank you, >>>> Sue >>>> _______________________________________________ >>>> caiman-discuss mailing list >>>> caiman-discuss at opensolaris.org >>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>
