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