Dave Miner wrote: > 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.
The inherent problem we have is that the dhcp server is what directs clients to go here or there. Yet we want to be able to dictate that with how create-service/create-clients are called. -ethan > > Dave
