Hi Darren, Comments inline.
Darren J Moffat wrote: > James Carlson wrote: >> I'm sponsoring this fast-track request for Jack Meng. The timer is >> set to 10/24/2008. >> >> Background >> >> By default, dhcpagent "canonizes" interfaces under its control on >> receipt of SIGTERM. This means that it will reset the IP address >> back to 0.0.0.0 during shutdown. This happens regardless of whether >> dhcpagent is configured to release or drop leases. > > I'm sure this was considered but why bother with the reset to 0.0.0.0 > on shutdown at all ? What does it achieve ? dhcpagent canonizes all interfaces upon receiving SIGTERM, which usually happends during shutdown/reboot/halt (kill(-1, SIGTERM)) to stop all processes. It makes sense in the view of DHCP protocol and harmless for most (if not all) userland processes as they usually have SMF dependencies. But this behavior hurts kernel elements (iSCSI, NFS..) which are based on TCP/IP stack and supposed to still work after 'kill(-1, SIGTERM)', e.g., to synchronize file system. > If that wasn't done would there be any need for this special knowlege > of iSCSI (and NFS) both of which seem very "icky" but if needs must. I think NO, no special knowledge needed if the configuration of the if doesn't change at all during shutdown. > What breaks if dhcpagent does not reset back to 0.0.0.0 on shutdown > ? Could it still send the DHCP release to the DHCP server but not > reset the interface ? It is a solution, but violating the protocol more severely. > > > When is dhcpagent going to call the new ioctl ? What are the > responses it gets back and what circumstances ? The proposal is to let dhcpagent to call the ioctl in its handler of SIGTERM. The response is either True or False indicating if there're active iSCSI sessions configured. > What if we have a "mixed" boot environment where one size of the > mirror in the ZFS root pool is local disk and the other is iSCSI ? > Does that count as being ISCSI_IS_ACTIVE? > What if there are no "boot" pools/filesystems under iSCSI but there > are other active iSCSI devices ? Yes, these circumstances stand for 'iSCSI active' as there're active iSCSI session and the system may have iSCSI disks in use (root partition or zpool or..). > > Is this only if there is an an iSCSI initiator active, what about > targets ? [ Though I wouldn't expect those machines to be iSCSI boot ]. > Current iSCSI target on Solaris in a service in userland, it addressed this issue well with SMF dependency, and also it is not supposed to still work after 'kill(-1, SIGTERM)'. Best regards, Jack
