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. > 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. > 3.3 > > Can you explain the difference between preconfigured > and user created AI images? The "preconfigured" AI images is really a preconfigured list of resources/locations where AI images can be obtained, if not available locally. I will clarify this in the spec. > 5.1.1 > > Does a service always have a default manifest? I thought > based on recent conversation we decided that a service > does not always have to have a default? 5.6.2 eludes to this. Yes, you are correct. It is possible to have a service without a designated default manifest, I will update this section to reflect that. > 5.1.2 > > Pros - second bullet - nit - can you change the structure of the > sentence to have the "if support for running ..." part come first? ok > 5.2 - third bullet - Does this sentence need updating now that > the subnet scope has been introduced? The intent was that subnet scope was covered here by using client-specific to include both MAC address and subnet address: "...a client-specific entry has been created for that client or group of clients. A client-specific entry can be based on client MAC addresses or address of subnet." But I can see that using "client-specific" is confusing in this context. I will reword this section to say that these scopes are client-related and then refer to client scope (MAC address) and subnet scope (subnet). > 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. > 5.4.3 - 7th bullet - would it be better to say that the install > service consumes the AI image, rather than the webserver? I assume you meant section 5.4.2? Yes, I'll change this. > 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. 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
