On (05/19/10 22:37), Erik Nordmark wrote:
>
> This looks identical to the case when vnic0 was configured locally in the
> ngz (that is what "static" means). Hence the NGZ admin have no reason to
> believe it isn't possible to do a ipadm delete-addr vnic0/_a.
>
> But either such a delete fails, or after a reboot the address magically
> reappers; either of which would be a surprise to the ngz admin since the
> addresses are marked as "static".
>
> These addresses provided and enforced by the GZ are provided by an external
> entity (the GZ) the same way as the addresses in a dhcp or addrconf address
> object are provided by an external entity (the dhcp server and stateless
> addrconf config on the routers, respectively. Thus I think it makes sense to
> label them as a different type of address object to make this clear to the
> ngz admin
>
> I don't know what a good name would be - we used "from_gz" when we talked
> about this on the phone.
>
> That way the ngz admin will see something like
> vnic0/_a from_gz ok 11.1.1.1/24
> vnic0/_b from_gz ok 12.2.3.4/16
> hence have visibility into the origin of these addresses. (Perhaps all
> addresses can be part of the same vnic0/_a address object, just like
> addrconf address objects contain multiple addresses, but that is a detail.)
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.
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.
Thoughts?
--Sowmini
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
