On Thu, 2009-09-03 at 22:00 -0400, James Carlson wrote: > Sebastien Roy wrote: > > On Thu, 2009-09-03 at 15:58 -0700, Danek Duvall wrote: > >> My only other comment (and this is more in your domain that ours) is that > >> it sounds like this needs to be done earlier in boot -- won't network > >> connections already be established by the time this service runs, and won't > >> that make changing this configuration problematic? > > > > It adds a property to existing VLAN links, and this property won't be > > needed unless and until an administrator creates a bridge instance using > > dladm create-bridge (introduced by this project). It doesn't need to be > > done early in boot since the administrator won't have the opportunity to > > create a bridge until the login service has started. > > It's only tangential to this discussion, but that's not quite the case. > > The property being added is a generic one. We noticed that the > implementation lacked a standards-compliant Port VLAN Identifier (PVID) > when we were doing the bridge design work, but the feature itself does > in fact do something even when you don't use bridging. > > If you have no VLAN 1 configured on a given port, then we'll set the > PVID to 1 (per the standards; making the assumed VLAN for that port be > 1), and you will *not* then be able to create a VLAN 1 on the port. > > If you do have a VLAN 1 configured, then we'll set the PVID on that port > to 0 (outside of the standard; meaning "no PVID"). > > Once the upgrade is complete, you can change the PVID whenever you want, > and that changes the assumed VLAN for the port. > > Per the standards, we assume PVID 1 if we can't find it in the > configuration file. > > The point of all that is that if (for some reason) the upgrade script > isn't run, and if you happen to have a VLAN 1 configured on some port, > then the VLAN will fail out at boot time, because the kernel won't allow > the object to be created. The upgrade script avoids that failure mode.
This is good information (and not just tangentially related), because that implies that the dladm commands that set the pvid property on the ports have to run before network/physical, when VLANs are brought online. That pretty much discards the SMF upgrade method entirely because network/physical runs before manifest/import. Option (1) would then seem like the only viable option (parsing the datalink.conf file from svc-dlmgmtd and adding dladm commands to the existing upgrade_datalink script that runs from net-physical). -Seb _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
