Dave Miner wrote: > Jan Damborsky wrote: >> Hi Dave, >> >> Dave Miner 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'm concerned about scenario 4 assuming that DHCP servers (and AI >>> servers) would be provided per-subnet. This would be fairly unusual >>> and undesirable in my experience, as it scales poorly in >>> administrative overhead. Does this make any substantive difference >>> in the solution? >> >> In current proposal, it is possible that one AI server and DHCP >> server take care of multiple >> subnets. The general limitation is that only one service with global >> scope can be created >> per one AI/DHCP server - client specific setup would be needed for >> rest of the clients. >> >> This scenario assumes that client types are mostly grouped by subnets >> (e.g. lab subnets, >> offices, ...) and that administrator would prefer to create install >> service with global >> scope per each subnet. >> > > I would assume that by manually placing the correct options within the > network macro, you would get the same effect. Is there a reason this > wouldn't be the case?
This is a good point - that should work for both x86 as well as Sparc (as Sparc can also define wanboot.conf per subnet). I am thinking how it might affect the concept of the scopes. In the install service redesign proposal sent out yesterday, two scopes are defined - 'global' and 'per client'. I can think about following approaches, if we would like to have 'per subnet' granularity: [1] introducing new 'per subnet' scope Then we would have three scopes (from the most specific to the most generic): * per client - applied to the client with per client binding * per subnet (one per architecture) - applied to clients in the matching subnet which don't have per client binding * global (one per architecture) - applied to the rest of clients [2] changing 'global' scope to 'per subnet' scope There would be two scopes then * per client - applied to the client with per client binding * per subnet (one per architecture) - applied to clients in the matching subnet which don't have per client binding - if subnet not provided, the one AI server is connected to would be picked up > If it is, what could we add to the administrative tools to make that > easier? I will let Frank comment on this, as I think it changes the concept we have been discussing, since we have been assuming that there would be possibility to create only one service per architecture with global scope on AI server. With 'per subnet' scope there might be more than one such services (limited by number of subnets AI server is supposed to handle). Jan
