Sarah Jelinek wrote: > Dave Miner wrote: >> jan damborsky wrote: >>> Hi Dave, >>> >>> >>> On 04/15/09 18:12, Dave Miner wrote: >>>> jan damborsky wrote: >>>>> On 04/15/09 16:59, Sarah Jelinek wrote: >>>>>> Alok Aggarwal wrote: >>>>>>> On Wed, 15 Apr 2009, Ethan Quach wrote: >>>>>>> >>>>>>>>> Proposed fix for now: >>>>>>>>> --------------------- >>>>>>>>> For now any significant design changes are not appropriate, >>>>>>>>> since they would be too risky. Based on this I am thinking about >>>>>>>>> following temporary solution before final approach can be taken: >>>>>>>>> >>>>>>>>> * when new service is created, don't touch >>>>>>>>> /etc/netboot/wanboot.conf >>>>>>>>> if it contains pointer to existing boot archive. It makes sure >>>>>>>>> that once /etc/netboot/wanboot.conf is created for one service, >>>>>>>>> it is not accidentaly overwritten by another service. So >>>>>>>>> clients would >>>>>>>>> continue to use first service as a default (in cases >>>>>>>>> 'create-client' >>>>>>>>> is not called) and mismatch would be avoided in this case. >>>>>>>> But if we create a second sparc service (say with build N+3, or N-3 >>>>>>>> for that matter), then clients trying to use the second sparc >>>>>>>> service >>>>>>>> will get a mismatch still, right? >>>>>>> I think there still will be a mismatch. >>>>>>> >>>>>>> The only sure fire way of ensuring no mismatches >>>>>>> in the current design would be to force the sparc >>>>>>> users to use create-client. But again that's a clunky workaround >>>>>>> and needs to be debated whether >>>>>>> it is acceptable for this release. >>>>>> I think that a possible solution is to force users to do a >>>>>> create-client and not use the /etc/netboot/wanboot.conf file at >>>>>> all. would this be something we could consider? That way we don't >>>>>> have a mismatch. >>>>> Given the issues we have with other approaches, that seems like >>>>> a good solution at this point. >>>>> >>>>> If we create service and /etc/netboot/wanboot.conf is not created, >>>>> then client doesn't boot until create-client is called. We could >>>>> document it as limitations for Sparc clients for this release. >>>>> And if create-service realizes that the service is created for >>>>> Sparc, appropriate message would be displayed in order to let >>>>> the user know. >>>>> If people don't have objections, I would go with this approach. >>>>> >>>> I object. This seems excessively restrictive. Having >>>> create-service fail if there is already a service seems more >>>> reasonable to me. >>> Thinking about this solution, it seems that this approach >>> might be considered less flexible than forcing Sparc AI >>> client to be explicitly associated with particular service. >>> >>> If I understand correctly how people currently use it, >>> they usually create one service associated with particular >>> AI image. Based on this, allowing that only one service >>> can be available for all AI Sparc clients may actually >>> be less convenient for them. >>> >>> Also, when we go this way, we still need to resolve how >>> to update DHCP server with the information about newly >>> created service when -i -c option are not specified to >>> explicitly force updating IP pool. >>> >> Any proposal that requires a create-client for each client is a >> non-starter. >> > I agree with Jan. I think forcing users to have only one sparc service > for all sparc clients is worse than asking them to run a create-client > for each client. This could be scripted to do multiple clients at a time. >
I'm not in agreement. For the simple cases where you have lots of clients and only care about having one service, having to individually configure each client is just not acceptable. I would expect that the default wanboot.conf file should only be updated in the case where a service is explicitly designated to be the default service. Otherwise, it's just a random service that will later be assigned to some clients using create-client. This is where the unimplemented default service functionality in installadm would have been used. Dave
