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.
I agree with Ceri in that this approach can break other zones without
any warning.
Leaving obsolete around is a much lesser evil than deleting a route that
other zones
are currently using.
Jarrett
>
> --Glenn
