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.
sarah > Dave >
