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.
--Glenn
