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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list