On 3/9/07, Wee Yeh Tan <[EMAIL PROTECTED]> wrote:
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
> special here?
> 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"
Stupid. I missed out Rainer's email somehow.
zones-discuss mailing list