> > The ovirt-early script uses the standard ip= and ipv6= kernel command line > > options to bring up autoconfigured network interfaces. The interface to > > bring up can be specified using the standard BOOTIF= kernel cmdline arg. > > So what you're talking about should work fine, as both ip= and ipv6= both > > support dhcp as an argument. > Sure, except AFAICT, this won't bring up networking until after we've > attempted to mount /config ... which is of course too late if we're > using an iscsi "local" disk.
right, ovirt-early is only parsing ip parameters, they're used for the firstboot configuration in stand-alone mode. But let me try to understand the use-case here: is this PXE boot of the node image with /config on iSCSI ? B/c with iSCSI root networking must be brought up even earlier in initrd, right? In any case, for boot parameters we should reuse or make compatible with Dracut parameters http://sourceforge.net/apps/trac/dracut/wiki/commandline > Oddly enough, we pxe from our 1g nics, but want to bond the 10g > nics... > I'd prefer specifying input for creating a bond, or bonds... I guess bonding should be added to Dracut as well, let's propose it there. Dracut has bridge parameter which could be extended: http://sourceforge.net/apps/trac/dracut/wiki/commandline#Bridging > BONDIF=bond0,bond1 > bond0_MACS=$primary_mac,$secondary_mac > bond0_OPTIONS="mode=6 miimon=100 use_carrier=1" > bond0_PROTO="dhcp" > bond0_ONBOOT="yes" > bond1_MACS=$primary_mac,$secondary_mac > bond1_OPTIONS="mode=6 miimon=100 use_carrier=1" > > We'd also need bridging parameters so we can configure a bridge with > the > bond port... > BRIDGEIF=brbond0 > > >> ... But regardless, it is probably worth creating an easy to use > > >> interface > > >> for vendors to add their own init scripts in without needing to duplicate > > >> code, and trampling on ovirt-early. Perhaps an > > >> /etc/insert-your-vendor-script-here.d directory that ovirt-early and > > >> ovirt-post reads and executes functions from? That would provide an easy > > >> way to drop in custom functionality and would also not require a new > > >> kernel cmdline param. Thoughts? > > > > > > That does seem cleaner; though I do still like having a way to choose > > > which set of vendor scripts to run via kernel parameter. We'd like to > > > have a single iso image that we could support different types of startups. There's already similar hooks folder /etc/ovirt-config-boot.d/ (scripts there are executed after upgrade). What about /etc/ovirt-early.d/ where vendor could put pre-* and post-* scripts and parameter would then select one or more scripts to execute: ovirt_early=*) i=${i#ovirt_early=} ovirt_early=$(echo $i|tr ",:;" " ") ;; EARLY_DIR=/etc/ovirt-early.d for hook in $ovirt_early; do pre="$EARLY_DIR/pre-$hook" if [ -e "$pre" ]; then . "$pre" fi done ... for hook in $ovirt_early; do post="$EARLY_DIR/post-$hook" if [ -e "$post" ]; then . "$post" fi done _______________________________________________ Ovirt-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/ovirt-devel
