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