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

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.