> Sebastien Roy wrote: >> David Bustos wrote: >>> Quoth Sebastien Roy on Wed, Oct 10, 2007 at 06:48:02 -0400: >>>> Cathy Zhou wrote: >>>>> 1. Instead of write those "dladm" commands to >>>>> /var/svc/profile/upgrade, we write it to another script, and run >>>>> that script at the very beginning of network/physical service. >>> >>> That should work, I think. >> >> The downside of this one, however, is you now have this upgrade turd >> in the network/physical method script that is run forever. >> Seb/Team,
After I think about this more. I'd like to propose another option - to defer the creating and plumbing of aggregations later. Today we already defer the plumbing of the iptun to the network/initial service. The proposal would solve the problem caused by late running of /var/svc/profile/upgrade. It also solves another problem: Today device/local is the service that that iterates and attaches all the network devices (therefore we know of the existence of a new network data-link). It is especially important during a reconfiguration boot. The device/local service also runs very late, and because network/physical runs before device/local, the "dladm create-aggr -d bge0 1" command might fail because it fails to find the device bge0. One might ask how "ifconfig bge0 plumb" works - it works because libdlpi tries to open the /devices pseudo clone device node. What do you think? What's your plan for those iptun interfaces. Thanks - Cathy
