[libvirt] RFC: adding configuration for standard dhcp options to <network>

[Michal Privoznik]

On 26.11.2012 21:12, Laine Stump wrote:
> On 11/24/2012 04:41 PM, Laine Stump wrote:
>> There have been multiple requests over the last couple years to make the
>> DHCP server of libvirt's virutal networks more configurable (for
>> example, see the following BZ:
>> https://bugzilla.redhat.com/show_bug.cgi?id=824573 ).
>>
>> You can see a full list of the options supported by dnsmasq with this
>> command:
>>
>>    dnsmasq --help dhcp
>>
>> The biggest question here is in exactly how to represent the options in
>> the network XML. I can see a few different options, among them:
>>
>> 1) make each option its own element within <dhcp>, e.g.:
>>
>>      <dnsServer family='ipv4' address='x.x.x.x'/>
>>      <dnsServer family='ipv6' address='xxxx:xxxx::1'/>
>>      <ntpServer address='y.y.y.y'/>
>>      <smtpServer address='z.z.z.z'/>
>>
>> 2) A variation of (1) where each option could appear only once, but with
>> two attributes, one for ipv6 address and one for ipv4:
>>
>>      <dnsServer address4='x.x.x.x'address6='xxxx:xxxx::1'/>
>>      <ntpServer address4='y.y.y.y'/>
>>
>> 3) have a repeatable "option" element (again, a subelement of <dhcp>
>> that can contain any number of the options as attributes:
>>
>>      <option family='ipv4' dnsServer='x.x.x.x' ntpServer='y.y.y.y'
>> smtpServer='z.z.z.z'/>
>>      <option family='ipv6' dnsServer='xxxx:xxxx:1'/>
>>
>>   (in this case, we may or may not support repeating <option> to add
>> more options for the same family).
>>
>> 4) yet another variation, where each option is a subelement of <option
>> family='xxxx'>:
>>
>>      <option family='ipv4'>
>>        <dnsServer>x.x.x.x</dnsServer>
>>        <ntpServer>y.y.y.y</ntpServer>
>>        <smtpServer>z.z.z.z</smtpServer>
>>      </option>
>>      <option family='ipv6'>
>>        <dnsServer>xxxx:xxxx::1</dnsServer>
>>      </option>
> 
> 5) With so many options, it may save lots of repetitive code in the
> parser/formatter to make a generic <option> element:
> 
>        <option name='dns-server' value='x.x.x.x'/>
>        <option name='ntp-server' value='y.y.y.y'/>
>        <option name='smtp-server' value='z.z.z.z'/>
>        <option family='ipv6' name='dns-server' value='xxxx::1'/>
>        <option number='201' value='/netboot/boot-dir/' force='yes'/>
> 
> The final is an example of something I just noticed in the BZ I
> mentioned above - it is both using an option number and forcing the
> option to be sent back to the client even if the client doesn't request
> it. This is apparently needed for some clients.
> 
> There is a precedent for the "name/value" type of object in nwfilter
> parameters. The advantages in this case are
> 
>   a) the code for the parser couple possibly be much smaller, with just
> a single
>      enum + VIR_ENUM_(DECL|IMPL)
> 
>   b) it would be easier to support the options by number (which are all
> defined
>      somewhere in RFCs, but not all have mnemonic equivalents in dnsmasq)
> 
> On the other hand, if we allowed any possible option by specifying a
> number (and even if not, depending on how the parser was implemented),
> it would be easier to create a situation where "bad stuff" could be
> injected into the dnsmasq commandline (we should have some type of
> intelligent parsing of the values - known options should have a type
> associated with them, and unknown should at least be checked for
> dangerous characters).
> 
> Any opinions from those with more XML experience?

I lean towards 5) because I think it's the most general description.
Sometimes I find myself in situation where I'm working on a new feature
and the most time I spend thinking how to suit it into XML because this
element is too narrow for it and I don't want to invent a new one, or
something.

Michal