On Thu, Jan 31, 2008 at 07:03:47AM -0800, Glenn Faden wrote:
> James Carlson wrote:
> >Jarrett Lu writes:
> >
> >>So far, I don't see a cliff yet. Ed's concern is mostly about not
> >>cleaning up
> >>default routes after zones are halted. While I think Ed has a point, I
> >>don't
> >>see zones not cleaning up their default routes upon halting as a disaster.
> >>We already have situations that default/static routes don't get cleaned up
> >>after they are no longer needed.
> >>
> >
> >I agree with Ed that failing to remove the routes is sloppy. It means
> >that a simple reconfiguration ("oh, the router is .2 here and not
> >.1!") using the documented interfaces results in a broken system --
> >one with two routes, one good and one bad, leaving the administrator
> >to clean up after it.
> >
> >That's not a great idea. It's possible that this would be acceptable
> >for TX, where all zones behave as a collective and where
> >administration practices might be more constrained, but I can't see it
> >being that way otherwise.
> >
> >A somewhat simple solution could be implemented in zoneadmd. You'd
> >have to keep track of the routes you add as you add them, and note the
> >duplicates. Then, when the zones shut down, delete the route when the
> >last zone using it goes away.
> >
>
> How can you tell you are the last zone? It seems that some kind of
> shared reference counter would be required which is synchronized among
> all instances of zoneadmd, for each default route.
>
> Unless someone can explain how to do this better, I will amend my
> proposal as follows:
>
> 1. Each zoneadmd will keep track of routes that it was successful in
> establishing. It will remove such routes when it halts a zone.
>
> 2. If the attempt to create the route fails with EEXIST, a warning
> message is printed stating that the route is was previously established
> and may be removed by another zone.That means that duplicate (shared)
> routes are permitted, but discouraged, since they will fail if the first
> zone to set this route is halted.
>
> It should be noted that this information will be lost if zoneadmd dies
> and is restarted. That shouldn't be happening, but there is logic in
> zoneadm to restart a failed daemon.
>
> This approach has the opposite problem that it cleans up too
> aggressively instead of leaving obsolete routes. I still think it is an
> improvement over the current lack of support for defualt routes for
> zones. A follow on project could implement reference counters to
> determine when routes are no longer in use.
>
the state wrt how routing was configured should be saved as a zone
property. that way if zoneadmd dies and is restarted it can check
this information. i would also be possible for zoneadmd to query
this attribute for all zones on the system, and using ipc, to have all
the zoneamd copies coordinate to essentially implement reference
counting which zones are using which routes.
this also doesn't address the other issue i raised.
two zones on the same subnet with different default routes should
be a configuration error, since there are no guarantess that
once both routes are added to the system the zone will actually
use the default route that it was configured. each zone could
use both default routes.
ed
