jan damborsky wrote: > On 04/15/09 18:21, Ethan Quach wrote: >> jan damborsky wrote: >>> The temporary fix suggests to 'lock' that file by the service which >>> accessed it first and 'release' it once service along with AI image >>> is deleted. I agree there are issues with this approach. >>> >>>> DHCP config is totally secondary. A user who just moderately knows >>>> what they are doing can subsequently manually add IP addresses >>>> associated >>>> with the service_2 macro created above. >>> I am not sure we could expect the user to take care of this. My feeling >>> is that if there are steps required which can't be either accomplished >>> by installadm(1M) tools itself or by copy-paste of the output those >>> tools >>> produced we shouldn't support/allow such scenario. >> I'm not suggesting that we're pushing anything to the user. I'm >> suggesting >> that it's possible that a keen user could intentionly not issue -i -c, >> knowing >> he/she is going to manually do it later because they just want to. > > I see - I got it now :-) > >>>>> service_1 will continue to be used by default (if 'create-client' >>>>> is not >>>>> called). >>>>> >>>>> Mismatch doesn't occur. >>>>> >>>>> [2] installadm create-service -n service_2 -i <IP_start_2> -c >>>>> <IP_pool_size_2> >>>>> -s <ai_iso_2> <ai_image_2> >>>>> >>>>> * /etc/netboot/wanboot.conf will still point to service_1 boot >>>>> archive. >>>>> * two disjoint sets of IP pools will be available >>>>> one for service_1 associated with service_1 dhcp macro, >>>>> one for service_2 associated with service_2 dhcp macro >>>>> >>>>> New client connected to the network would obtain boot archive from >>>>> image_1, >>>>> but I am not sure how DHCP server behaves in this situation - from >>>>> which >>>>> pool it will assign IP address ? Is this deterministic/supported >>>>> scenario ? >>>> Nope, its random. A client can be given an IP of either pool. >>>> >>>> Its not a deterministic scenario. I've yelled about this before, >>>> but its >>>> apparently a designed usage case. >>> >>> Is it captured somewhere to take a look at ? To be honest, >>> I am not sure how it might be useful for client since it >>> is not known what it is going to boot. >> You are preaching to the quire :-) >> >> I think the usage scenarios are at the end of the design doc. In a >> nut shell, from what I recall, the usage case was: >> >> Admin wants to quickly set up 20 machines for his class. 10 machines >> will be installed with X, 10 machines will be installed with Y. >> Admin >> doesn't care which machines installs X and which installs Y. Admin >> does two create-service calls, one for X and one for Y, each with >> their >> own -i -c. Admin does "boot net" for all 20 machines. Done. > > To be honest, this one seems a little bit artificial, but to tell the truth > my admin experience is really limited. > >> >> (And obviously from this bug, one of those sparc services will get a >> mismatched boot archive ;-) ) >> >> Putting aside our opinion of its usefulness for a bit, I think a part >> why we're here now is because this scenario is least worked properly >> for x86. When sparc came along, we didn't reevaluate whether it >> actually worked for sparc. > > I agree - in current implementation (based on how wanboot works and what > it allows), that scenario can't be accomplished for Sparc. >
It's not really a useful scenario, as seldom is a user in a situation where they'll say "Hey, I don't care which of two different possible installations gets applied to a particular system". The useful scenario is one in which there is a default installation that's used for standard systems, and then there are other installation services which are used for specific exception systems. The latter are what you'd use create-client for; the former should just use the default service. Dave
