After much discussion we have reached consensus that the original
proposal is satisfactory. We have received feedback on this alias,
other OpenSolaris forums, and private correspondence encouraging us to
provide this feature without additional restrictions. We will provide
documentation in the appropriate administrative chapters about the
appropriate uses and limitations associated with applying default zone
routes.
Although it is agreed that the proposal could be improved by keeping
reference counts for which zones are using each route, such an
enhancement might be quite complicated to develop and test and isn't
required in order for customers to take advantage of the default routes.
The project team has already initiated a project to provide the ability
to remove per-zone default routes when the zone is halted.
--Glenn
Jarrett Lu wrote:
> 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
>
