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.
>
This has a better chance of working if default routes can *only* be added
by zonecfg/zoneadmd. If someone manually adds a default route, without
knowledge of zoneadmd, we are back to a non working system again.
To manage a shared resource correctly, we need to have a reference count.
The best place to keep the count is in kernel, I believe.
> That has the benefit of working for both TX and regular cases, of
> allowing the configuration that Ceri Davies wanted, and not leaving
> any mess around afterwards.
>
>
>> Your earlier suggestion about adding zoneid to route(1M) is interesting.
>> When ire_zoneid is set explicitly by "zoneid", it's clear who set the ire
>> entry, who can use the entry, and who should clean up the entry. It also
>> implies that the routing table could have many almost identical entries
>> that only differ in ire_zoneid. This may have performance implications
>> when finding a matching entry. Anyway, we haven't thought about
>> the design enough.
>>
>
> That's possible, but seems like deeper and riskier surgery to me,
> particularly for something intended to be released as a patch.
>
>
That's a good point. Many TX customers require a lengthy and expensive
certification on the OS before they can deploy it. Sun certifies Update
Releases,
but probably no plan to certify onnv any time soon. We do need a solution
that fits Update Release model.
Jarrett
