Hi Dave, thank you very much for your valuable comments, please see my response in line.
Jan Dave Miner wrote: > A couple of design-level questions: > > - Why is DNS domain used, but not DNS search path? The latter > provides more capability to the user. The initial intent was to configure DNS in the same way as it is done when DHCP network configuration strategy is used - /lib/svc/method/net-svc obtains values of DNSserv and DNSdmain DHCP options and accordingly populates /etc/resolv.conf 'domain' and 'nameserver' entries - 'search' is preserved (empty in case of AI client). I agree that 'search' is more flexible, there is no technical reason not to pass it to AI client as well - if defined on AI server, it could be added to /etc/resolv.conf on AI client. Please let me know if you would prefer to have it added into /etc/resolv.conf on client side for manual network strategy. > > - In what instances would you possibly end up in the fallback > configuration code at 480 in live-fs-root? It seems to introduce a > fairly significant lack of determinism and it would be helpful to > understand the cases it solves. This fallback mechanisms would be tried in case /usr/lib/inet/wanboot/netbootinfo was not able to determine network configuration strategy. I haven't hit any real scenario when evaluating the fix - network strategy was always correctly determined. The intent here was to tried to bring up the network using all mechanisms available. Thinking about this more, I can see this actually might be source of problems - if there is any bug in algorithm which is used to determine the network strategy, it would be masked by this behavior. I think that the correct approach would be to fail in this case and appropriately inform the user that network strategy couldn't be determined - in that case the loop would be closed (I assume bug would be filed) and we will be provided with feedback that something is broken in that area. > > I'm really hoping that the refactoring that Alok is working on breaks > this method script down substantially - the size & complexity is well > beyond what I'd like to see and suggests to me that we perhaps haven't > integrated this into the existing system functionality as well as we > should. According to Alok's suggestion, at this point I am going to hold the fix and I will merge it with Alok's refactored services once AI bootable image project is integrated. I am thinking about where this functionality belongs. In general, as its purpose is to configure network (even if it is special case), we might [1] enhance existing network SMF services Since this is special scenario (Sparc wanboot manual configuration), which doesn't seem to be used outside of the installer technologies, it seems that it should be private to install consolidation. [2] Introduce modified 'live' version of one of network services and put the fix there. It would be similar approach which was already taken for other 'live' services. I am not quite convinced this is the right thing to do, as it leads to code duplication - any changes done to original service are likely to be lost and not propagated to 'live' version. [3] Introduce new SMF service living only in install consolidation. It would only contain network configuration specific to AI and LiveCD and thus wouldn't interfere with existing network SMF services. [4] Put that code into refactored services Alok will integrate As part of this effort, the fix would be decomposed into functions, moved into separate script to be included by one of Alok's services - which would then call the functions. It would definitely improve readability and should have been done anyway. [5] ? Do you think that following one of those approaches might address the concerns raised ? Or might there be another possibility to be considered as well ? > > Dave > > Jan Damborsky wrote: >> Hi Ethan, Sundar >> >> could I please ask one of you guys to review the fix for following bug ? >> Other reviewers are also welcome. >> >> 9549 Sparc AI client doesn't bring up network if not booted using DHCP >> >> * Webrev: >> http://cr.opensolaris.org/~dambi/bug-9549 >> >> Short story is that this fix add support for following scenarios: >> >> * Sparc Automated Installation without need for DHCP server >> (making Sparc AI more 'WAN') >> * Automated Installation of Sparc clients without wanboot support >> in OBP (wanboot binary loaded from media instead) >> >> Please see bug report for more details. >> >> Alok, as we were discussing during MPK work week, these modifications >> might affect bootable AI image (particularly refactoring SMF services >> part). >> Could you please take a look at those changes just to verify if there >> are any pieces which might be source of potential issues ? >> >> Thank you very much, >> Jan >> >> >> Modules affected and tested: >> * Distro Constructor (ai_sparc_image.xml - Sparc AI manifest) >> * AI client (live-fs-root) >> * installadm(1M) tools (set up for Sparc install.conf) >> >> tests carried out: >> * please see attached file for tests carried out >> and test results >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
