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. >> >> 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. Dave
