Sundar Yamunachari wrote: > Susan Sohn wrote: >> Notes from the meeting have been posted at: >> >> http://www.opensolaris.org/os/project/caiman/auto_install/ai_svc_scenario_mtg_0610.txt >> >> > I have few questions on the various use cases in the notes. > > About the dhcp setup: > > When you setup the IP addresses, what macro will be assigned in the > DHCP table? Will it be different for SPARC service and X86 service? > How will you ensure that the client will get the address that > correspond to the correct architecture? > Does the architecture specific macros interfere with per client > specific macros. If the DHCP server has a architecture specific macro > that points a global service and a client specific setup that points > to a different service, does the client specific macro override what > is specified in the architecture macro? The IP addresses are only used when setting up the AI controlled DHCP server and only refer to the range of dynamic addresses that server will manage. They do not control which service a booted machine will be directed to. (Correct Jan?)
The global service is the default service so it is used only if there is no client-specific macro that directs a client to a non-global service. > > In one of the other threads, it mentioned that we can create > generic macros with specific release or service and include them in > client class macros. So in the default case, will you be creating all > the client class macros? This may not be a good user experience if you > tell the user to create all the client class macros (When the dhcp > setup fails). AI server will attempt to setup client macros in the DHCP server, but if the AI server has no access, the macros will have to be added manually by the sysadmin for the DHCP server. > > About the global SPARC and X86 services: > > Do the SPARC and X86 services point to the same version of the image? By default, yes (though specific for that architecture). The user will be able to replace the AI image associated with any service though doing so will force the service associated manifests to be revalidated and possibly removed (after confirming with the user). > > About the image (in case 3): > > How does the service creation tool know where to look for images? > If we decide the image for a service based on the AI manifest > (version), how can we other manifests to the service? It seems too > restrictive. The AI service will look at some "well known" places for the AI image appropriate for the manifest specified when the service is created. The user can optionally specify an AI image which will be validated against the specified manifest. The user will have to do this if the AI server can not locate the appropriate image on its own. > > > About the use case 4: > > I have similar concerns as that of Dave. We cannot assume that > there is a DHCP server per subnet. Why we need a separate AI server > per subnet? No, we don't assume nor require an AI server per subnet but in some cases it may provide the easiest way to scale up in cases where groups of machines use incompatible versions (in the AI server sense) of software loads. Alternatively a single AI server could be setup with multiple services, one for each architecture/version, and manifests whose criteria specify the machines' MAC addresses for each machine that is to get that software load. Frank > >> >> >> On 06/09/09 11:06, Sue Sohn wrote: >>> There will be a meeting tomorrow to discuss user scenarios for the >>> service redesign. The following scenarios will be used as a start >>> point for the discussion: >>> >>> http://www.opensolaris.org/os/project/caiman/auto_install/ai_svs_redesign_scenarios.txt >>> >>> >>> >>> >>> Please allow 2 hours for the meeting. >>> >>> Here are the meeting details: >>> >>> AI Services user scenario meeting: >>> Wed, 6/10 >>> 8am PT/9am MT/11pm ET/5pm CEST >>> >>> USA Toll-Free: 866-839-8145 >>> Caller Paid (Intl): 215-446-3660 >>> Participant Code: 9041875 >>> >>> Thanks, >>> Sue
