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. 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. -ethan > > thanks, > sarah > *** >> Dave >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
