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
different hosts.

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.

Just me,
Wire ...
zones-discuss mailing list

Reply via email to