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.
>
>>> * when service is deleted along with associated AI image (by passing
>>> '-x' option) and if /etc/netboot/wanboot.conf file contains pointer
>>> to boot archive in that image, /etc/netboot/wanboot.conf will be
>>> deleted along with that AI image. It would avoid
>>> /etc/netboot/wanboot.conf pointing to non-existent AI image.
>>
>> If clients were using a second sparc service, and had been falling back
>> to whatever was being specified in /etc/netboot/wanboot.conf, then
>> doing this would mean that these clients fail to get a wanboot.conf at
>> all, right?
>
> If you've done a delete-service, all the configuration
> information relevant to that service should be blown away regardless
> of this bug.
>
> So, I think the above change should definitely be made
> in order to ensure no side effects happen from having
> vestigeal information about a service that was deleted.
>
> Alok
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
