Ethan Quach wrote: > > Dave Miner wrote: >> Ethan Quach wrote: >>> Sarah Jelinek wrote: >>>> 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. >>>>> >>>> These are good points. I think Dave's approach, that is failing a >>>> create-service, if a service already exists is a good one. Does >>>> doing this resolve the possible mismatch scenario? >>> So only one sparc service can exist on a server at a time? That doesn't >>> sound too appetizing. >>> >> No, I don't think that's what I was suggesting. There's only one >> default service, by definition. >> >>> What if we "guestimate" the usage and say a create-service with -i -c >>> won't >>> be allowed if /etc/netboot/wanboot.conf already exists. But do allow >>> create-service without -i -c. And we'll have to change >>> create-service without >>> -i -c to not create /etc/netboot/wanboot.conf -- expecting that the >>> user will >>> be doing subsequent create-clients with that service. >>> >> Why not implement -d (set as default) and not guesstimate (the flag >> was in the usage but unimplemented until last week)? > > What's the definition of the "default" install service as compared to > all other > install services on the system? What's the behavior afa how the server > responds to requests when such a "default" install service exists? > > I guess this is the first I've heard of this. I'm pretty sure its not > in the > design doc. >
We had such a concept previously. This is how wanboot was designed, anyway, which is why there's the search hierarchy of the various locations for the .conf file. Dave
