Dave Miner wrote: > Frank Ludolph wrote: >> Dave Miner wrote: >>> Susan Sohn wrote: >>>> Notes from the meeting have been posted at: >>>> >>>> http://www.opensolaris.org/os/project/caiman/auto_install/ai_svc_scenario_mtg_0610.txt >>>> >>>> >>> >>> I'm concerned about scenario 4 assuming that DHCP servers (and AI >>> servers) would be provided per-subnet. This would be fairly unusual >>> and undesirable in my experience, as it scales poorly in >>> administrative overhead. Does this make any substantive difference >>> in the solution? >>> >>> One thing I'm not grasping from these notes is how a non-global >>> service is converted to be a global service. Or is it there under >>> some other guise? I'm not quite sure I see the rationale for having >>> a reserved name for the global service, though. What does it solve? >> Primarily clarity. We use a reserved name because we want the global >> service to be *very* easy to establish initially and to be obvious >> when used in other operations e.g. adding a manifest. >> >> None of the scenarios suggested the need to convert a non-global >> service to global so there was no discussion. It seems straight >> forward to start with a standardized global service and modify it as >> needed. > > Seems like we're missing a scenario, then. The scenario I envision is > that I have deployed OpenSolaris 2009.xx as my default, then started > experimenting with OpenSolaris 2010.yy as it comes out. Once I'm > confident that I've tested it sufficiently for my application set, I'd > like to convert that 2010.yy service to the global default, and > relegate 2009.xx to the exception case where needed. That doesn't > seem to be well-supported here. Agreed. I had a flawed model of "global service". As Sarah pointed out this is really a DHCP related concept. In a WAN-based AI server setup where there would likely be multiple DHCP servers, each of those servers would likely have a non-client specific, ie "global" reference to the AI server. > >>> >>> WRT to DHCP, one thing to consider is how this behaves with >>> non-Solaris DHCP servers (ISC, primarily, though Windows could also >>> be of interest). The "macro" concept referenced here is specific to >>> the Solaris server, though groupings of options are available in ISC >>> and other servers. It would be more implementation-neutral to >>> merely refer to sets of DHCP options here, and consider how we might >>> meet the users on their territory by providing appropriate sample >>> input for other types of servers. >>> >>> Per item 5.3 in the summary: Did you consider providing a >>> user-definable ordering of the manifests, rather than the propsed >>> LIFO order? >> This wasn't discussed in the meeting; it was my addition. I did think >> about user-definable ordering. Ordering is easy with a list in a GUI, >> but lacking that probably a form of "put x before y" where the base >> would be the default manifest, whether defined or not. >> > > I'd suggest merely tagging each with a numeric value; the default has > value 0 (last) and services are evaluated in descending order. That > removes the problem of expressing relations between services. > "Insert at" is essentially the same as "put x before y". The manifests should certainly be listed and evaluated as you suggest.
Frank
