Sebastien Roy writes: > > 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 > pkg-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
You don't necessarily need to give up on approach 1. Tony Nguyen, Sean Wilcox and I are working on working on the Early Manifest Import project for SMF. It will run before any services start. We don't quite have a schedule yet, but will soon. Design notes can be viewed at http://anthrax.central/~tw21770/emi_design_1_8.html until we can get a permanent site on opensolaris.org. tom
