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. so, are you suggesting that create-service should fail if any other service was created? Then do we tell the user they must delete that service before configuring a new one?
> > Dave
