On 05/20/10 06:07 AM, [email protected] wrote:
If all we want is to keep the origin clear, that can be done by simply
setting an address flag (IFF_FROM_GZ) on addresses added by ipmgmtd, and
using that to print output in show-addr. But we discussed some more complex
issues on the phone, specifically the ability for the NGZ to persistently
set interface/address properties on the from_gz interface/addresses,
the ability to not have these things recreated on each reboot, and
the ability to recover from_gz information at any time after boot
using ipadm if, for example, vnic0 above got accidentally deleted.
Yes, it would be very odd if the ngz admin was not able to set
persistent interface properties, such as an mtu, just because the IP
addresses were provided from the global zone.
As we discussed on the phone, one solution for the anticipated
life-cycles for the "from_gz" address objects in ipkg excl-IP zones
would be
- on the first boot, set up vnic0 and and the from_gz addresses
persistently as far as ipadm is concerned,
- on subsequent boots the numeric values of address and mask for
from_gz objects are obtained from the nvlists set up by zoneadmd
in the kernel, everything else (for the interface and address) is
obtained from the persistent store
- the administrator can delete the interface/addresses associated
with the from_gz object at any time. The from_gz object, like dhcp
or addrconf, would map to several addresses, so address operations
would have to apply to all the addresses. That would necessarily
mean that the addrobj name would have to be the same for all the
addresses
- to recreate the from_gz interface after its been deleted, we'd need
a new
# ipadm create-addr -T from_gz vnic0/gzaddrs
- once an administrator has deleted the from_gz object that was handed
down from the GZ, it will never be recreated.
In contrast, the current proposal creates all the addrobjs (and the interface)
in the NGZ temporarily, so individual addresses (and address objects) can
be selectively modified/deleted temporarily at any time, and while the
administrator can delete/recreate the same address (object)
persistently, on the next reboot the GZ information will win.
The latter model is possibly simpler, though it admittedly allows the
NGZ less flexibility (esp in setting interface properties
persistently), and, short of restarting ipmgmtd, doesn't allow
the administrator to recover an accidentally deleted the "from_gz"
interface in a graceful way.
Most of your comments above, while correct, are about implementation and
not about the architectural and interface aspects of the proposal.
I think the added architectural material is a "from_gz" (or whatever it
makes sense to call it) type of address object, that has the same type
of behavior as seen by the ngz administrator as the addrconf or dhcp
type of address objects.
Erik
_______________________________________________
opensolaris-arc mailing list
[email protected]
