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

[Laine Stump]

On 11/27/2012 03:28 AM, Michal Privoznik wrote:
> 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.

Only sometimes? That's my biggest problem nearly 100% of the time :-)

Thanks for voicing an opinion. I'll try an implementation that way and
see how it turns out.