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. Thank you, Jan
