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