On 3/8/07, James Carlson <[EMAIL PROTECTED]> wrote:
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.
Indeed. We can spice this up more when zones can (and do) migrate to
I see this robustness becoming more important because zones have
encouraged the separation of services that would traditionally live
within the same box.
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
At best, I think we're talking about a minor boot-time optimization
rather than a fundamental way zones should interact.
How about approaching this by extending SMF to deal with "networked"
zones-discuss mailing list