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.
>
This seems like a reasonable approach to me.
> Thanks a lot !
> Jan
>
