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. Thank you, Jan
