[Ovirt-devel] [PATCH server] Replaced the config scripts with configuration encoding.

Darryl Pierce dpierce at redhat.com
Wed Oct 8 12:07:11 UTC 2008


Chris Lalancette wrote:
> This is definitely a step in the right direction.  I'm still a tiny bit
> concerned about using the generic "kmod", as opposed to just "bonding"; the
> former gives us more flexibility, but still leaves a security hole for loading
> any random kernel module.  The latter means that we have to implement something
> different for every new thing we want to support, but that's not necessarily a
> bad thing.  So instead of:
> 
> kmod=[module name]|[module alias]|[module options]
> 
> I think I would rather see:
> 
> bonding=alias|options

I'm fine with either direction. I did it for the flexibility, being able
to load other modules via the same mechanism. But there's no need for
doing so now, so I can easily move the code to use an implicit bonding
module instead.

> 
> For the ifcfg, that looks fine to me, as long as the number of delimited fields
> is unlimited, and all of the additional field would be put in the ifcfg- script.
>  That is, this is perfectly valid:
> 
> ifcfg=00:11:22:33:44|eth0|BOOTPROTO=dhcp|bridge=ovirtbr0|ONBOOT=yes
> 
> but so is:
> 
> ifcfg=00:11:22:33:44|eth0|BOOTPROTO=dhcp|bridge=ovirtbr0|ONBOOT=yes|DELAY=0

The code on the node side supports this. It expects the first two fields
to be the mac address and the iface name. Everything else it just moves
through, pulls out the key and value pairs and builds the augtool file
from them.

-- 
Darryl L. Pierce <dpierce at redhat.com> : GPG KEYID: 6C4E7F1B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dpierce.vcf
Type: text/x-vcard
Size: 319 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/ovirt-devel/attachments/20081008/21adfc01/attachment.vcf>


More information about the ovirt-devel mailing list