[Ovirt-devel] [PATCH] Add support for vendor hooks during ovirt-early start()

[Alan Pevec]

> > 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