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. When reading this I thought this too.
Jean >> >>>> * 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 > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
