Rainer J. H. Brandt writes: > And there you can see the answer: The clean thing to do is not to > add another abstraction (e.g. /etc/zones/boot_order), but to use > FMRIs referring to other zones or even remote hosts or zones on remote > hosts. And our SMF engineering friends obviously already thought > about that, as you can see when looking at this FMRI:
I also don't think that having another abstraction is right, however I don't think the FMRI approach is right either. If these zones were independent nodes on a network, we would never be having this conversation. Instead, you'd be told to do the normal networking thing: be robust. If your peer isn't ready when you are, then try again later. If your peer disappears on you, then log the problem, and try to reconnect. Once you get this boot ordering issue down, you'll ask about what to do when services inside one zone fail or are restarted and those outside the zone can't 'see' the change. So, why isn't this just an exercise in proper application design, and why are zones necessarily special here? At best, I think we're talking about a minor boot-time optimization rather than a fundamental way zones should interact. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ zones-discuss mailing list [email protected]
