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, doesn't it mean only one default sparc service? Seems to me we wouldn't override /etc/inetboot/wanboot.conf if users added a new service, unless they specified it as the default. Don't we have a provision for default in installadm now?
So, if the user adds a service that is not default, they must do a create-client to use that service. Is this doable? > 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
