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
zones-discuss@opensolaris.org

Reply via email to