Jan Damborsky wrote: > 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.
I think it would be better to support it. > >> - 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. > Thinking about this some more, I think the one case that can happen is RARP from the OBP (which I suspect you didn't try), but since we're not supporting that, having it fallback to DHCP in the case that it somehow got this far would be the wrong thing to do, so I think an explicit failure would be preferred. >> 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 ? > In general, I'd like us to not have special service instances for the install cases, because they represent opportunities for breakage when the default service instances are modified. The reason we have them right now is that it is currently simpler to maintain the live CD as a separate case and limit the skew in the installed system vs. what SXCE would obtain, thus keeping validity of installed system testing across both cases. But in the long run, we want changes to the core system to be considered for their install impacts as well, and so keeping separate instances in install-specific code would make that more difficult. Dave
