James Carlson writes:
> 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.
> 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?
They aren't. I think I should have changed the subject line.
(I've done that now.) And probably switched to another mail list.
(SMF? I hesitated because I hate cross-posting.)
I wasn't just talking about boot order. That probably wasn't clear.
That's just one of the many problems that could be solved by what I
suggested. And that was SMF across machines, which is what a cluster
or a Service Oriented Architecture is about, and which is what we
almost have with SMF. A real thing instead of all this marketing buzz
I mean this:
<dependency name='my-great-database' type='service'
<service_fmri value='svc://dbhost/application/postgresql' />
Wouldn't that be nice?
Do you see that attribute "restart_on"?
No, I won't ask the question that you mentioned up where I added the
[***] comment. I already know how to to that with SMF.
So, should we move this to the SMF list? Or forget it?
(As I said, there are most likely people who have thought about this.)
Rainer J. H. Brandt
Email: [EMAIL PROTECTED]
Brandt & Brandt Computer GmbH
Am Wiesenpfad 6, 53340 Meckenheim
Geschäftsführer: Rainer J. H. Brandt und Volker A. Brandt
Handelsregister: Amtsgericht Bonn, HRB 10513
zones-discuss mailing list