mbox series

[0/5] network: xmlns dnsmasq option passthrough

Message ID cover.1563148979.git.crobinso@redhat.com
Headers show
Series network: xmlns dnsmasq option passthrough | expand

Message

Cole Robinson July 15, 2019, 12:03 a.m. UTC
There's several unresolved RFEs for the <network> bridge
driver that are essentially requests to add XML wrappers
for underlying dnsmasq options.

This series adds a dnsmasq xmlns namespace for <network>
XML that allows passing option strings directly to the
generated dnsmasq config file. It will allow motivated
users to work around libvirt until those types of RFEs
are properly implemented.

Cole Robinson (5):
  conf: Add virNetworkXMLOption
  conf: Add network xmlopt argument
  conf: Add virNetworkXMLNamespace
  network: wire up dnsmasq option xmlns
  docs: formatnetwork: Document xmlns:dnsmasq

 docs/formatnetwork.html.in                    |  22 +++
 docs/schemas/network.rng                      |  11 ++
 src/conf/domain_conf.c                        |   2 +-
 src/conf/network_conf.c                       |  91 +++++++--
 src/conf/network_conf.h                       |  51 ++++-
 src/conf/virnetworkobj.c                      |  50 +++--
 src/conf/virnetworkobj.h                      |  13 +-
 src/esx/esx_network_driver.c                  |   4 +-
 src/libvirt_private.syms                      |   1 +
 src/network/bridge_driver.c                   | 182 ++++++++++++++++--
 src/network/bridge_driver.h                   |  12 ++
 src/network/bridge_driver_platform.h          |   2 +
 src/qemu/qemu_process.c                       |   2 +-
 src/test/test_driver.c                        |  11 +-
 src/vbox/vbox_network.c                       |   4 +-
 tests/Makefile.am                             |  14 +-
 .../networkxml2confdata/dnsmasq-options.conf  |  18 ++
 tests/networkxml2confdata/dnsmasq-options.xml |  15 ++
 tests/networkxml2conftest.c                   |   8 +-
 tests/networkxml2firewalltest.c               |   2 +-
 tests/networkxml2xmlin/dnsmasq-options.xml    |  15 ++
 tests/networkxml2xmlout/dnsmasq-options.xml   |  17 ++
 tests/networkxml2xmltest.c                    |  11 +-
 tests/networkxml2xmlupdatetest.c              |   4 +-
 24 files changed, 478 insertions(+), 84 deletions(-)
 create mode 100644 tests/networkxml2confdata/dnsmasq-options.conf
 create mode 100644 tests/networkxml2confdata/dnsmasq-options.xml
 create mode 100644 tests/networkxml2xmlin/dnsmasq-options.xml
 create mode 100644 tests/networkxml2xmlout/dnsmasq-options.xml

-- 
2.21.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Comments

Laine Stump July 17, 2019, 4:49 p.m. UTC | #1
On 7/14/19 8:03 PM, Cole Robinson wrote:
> There's several unresolved RFEs for the <network> bridge

> driver that are essentially requests to add XML wrappers

> for underlying dnsmasq options.

>

> This series adds a dnsmasq xmlns namespace for <network>

> XML that allows passing option strings directly to the

> generated dnsmasq config file. It will allow motivated

> users to work around libvirt until those types of RFEs

> are properly implemented.



This all looks like a reasonable facsimile of the qemu:commandline 
stuff, and it worked in my tests (including not creating any problems 
with all the existing networks I have on my test system).


My one reservation would be that it will tend to discourage adding 
*supported* methods of configuring things that people will instead use 
this backdoor to implement. But on the other hand, it makes it possible 
to do new things without needing to wait for an officially supported 
method (which could take a very long time, or simply never happen, as 
we've seen).


(Actually I for some reason thought we already *had* support for the 
specific example you used - CNAME records. I guess I had lumped it in 
with SRV and TXT records in my memory. It really should be 
straightforward to do, and should still be done, but that shouldn't stop 
this patch series from going in).


This is for the entire series:


Reviewed-by: Laine Stump <laine@laine.org>



>

> Cole Robinson (5):

>    conf: Add virNetworkXMLOption

>    conf: Add network xmlopt argument

>    conf: Add virNetworkXMLNamespace

>    network: wire up dnsmasq option xmlns

>    docs: formatnetwork: Document xmlns:dnsmasq

>

>   docs/formatnetwork.html.in                    |  22 +++

>   docs/schemas/network.rng                      |  11 ++

>   src/conf/domain_conf.c                        |   2 +-

>   src/conf/network_conf.c                       |  91 +++++++--

>   src/conf/network_conf.h                       |  51 ++++-

>   src/conf/virnetworkobj.c                      |  50 +++--

>   src/conf/virnetworkobj.h                      |  13 +-

>   src/esx/esx_network_driver.c                  |   4 +-

>   src/libvirt_private.syms                      |   1 +

>   src/network/bridge_driver.c                   | 182 ++++++++++++++++--

>   src/network/bridge_driver.h                   |  12 ++

>   src/network/bridge_driver_platform.h          |   2 +

>   src/qemu/qemu_process.c                       |   2 +-

>   src/test/test_driver.c                        |  11 +-

>   src/vbox/vbox_network.c                       |   4 +-

>   tests/Makefile.am                             |  14 +-

>   .../networkxml2confdata/dnsmasq-options.conf  |  18 ++

>   tests/networkxml2confdata/dnsmasq-options.xml |  15 ++

>   tests/networkxml2conftest.c                   |   8 +-

>   tests/networkxml2firewalltest.c               |   2 +-

>   tests/networkxml2xmlin/dnsmasq-options.xml    |  15 ++

>   tests/networkxml2xmlout/dnsmasq-options.xml   |  17 ++

>   tests/networkxml2xmltest.c                    |  11 +-

>   tests/networkxml2xmlupdatetest.c              |   4 +-

>   24 files changed, 478 insertions(+), 84 deletions(-)

>   create mode 100644 tests/networkxml2confdata/dnsmasq-options.conf

>   create mode 100644 tests/networkxml2confdata/dnsmasq-options.xml

>   create mode 100644 tests/networkxml2xmlin/dnsmasq-options.xml

>   create mode 100644 tests/networkxml2xmlout/dnsmasq-options.xml

>


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Cole Robinson July 17, 2019, 9:38 p.m. UTC | #2
On 7/17/19 12:49 PM, Laine Stump wrote:
> On 7/14/19 8:03 PM, Cole Robinson wrote:

>> There's several unresolved RFEs for the <network> bridge

>> driver that are essentially requests to add XML wrappers

>> for underlying dnsmasq options.

>>

>> This series adds a dnsmasq xmlns namespace for <network>

>> XML that allows passing option strings directly to the

>> generated dnsmasq config file. It will allow motivated

>> users to work around libvirt until those types of RFEs

>> are properly implemented.

> 

> 

> This all looks like a reasonable facsimile of the qemu:commandline

> stuff, and it worked in my tests (including not creating any problems

> with all the existing networks I have on my test system).

> 

> 

> My one reservation would be that it will tend to discourage adding

> *supported* methods of configuring things that people will instead use

> this backdoor to implement. But on the other hand, it makes it possible

> to do new things without needing to wait for an officially supported

> method (which could take a very long time, or simply never happen, as

> we've seen).

> 

> 

> (Actually I for some reason thought we already *had* support for the

> specific example you used - CNAME records. I guess I had lumped it in

> with SRV and TXT records in my memory. It really should be

> straightforward to do, and should still be done, but that shouldn't stop

> this patch series from going in).

> 

> 

> This is for the entire series:

> 

> 

> Reviewed-by: Laine Stump <laine@laine.org>


Thanks, I've pushed this now.

Regarding the bigger point, I think it's worth considering whether we
should aim to expose every requested dnsmasq option as official XML or
not. We effectively have one network driver; there's an impl for vbox
and esx but they seem very basic. It doesn't look like we are going to
have another backend impl any time soon.

Unless the requested option has some specific reason to be represented
in libvirt XML, like if another part of libvirt may need/want to
programmatically act on that data for some reason, maybe it's okay to
say that dnsmasq passthrough is the solution. Some examples might be

* dhcp-option: https://bugzilla.redhat.com/show_bug.cgi?id=666556
* auth-zone: https://bugzilla.redhat.com/show_bug.cgi?id=1690943
* This bug has a lot of mentioned options:
https://bugzilla.redhat.com/show_bug.cgi?id=824573

- Cole

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Daniel P. Berrangé July 18, 2019, 8:59 a.m. UTC | #3
On Wed, Jul 17, 2019 at 05:38:51PM -0400, Cole Robinson wrote:
> On 7/17/19 12:49 PM, Laine Stump wrote:

> > On 7/14/19 8:03 PM, Cole Robinson wrote:

> >> There's several unresolved RFEs for the <network> bridge

> >> driver that are essentially requests to add XML wrappers

> >> for underlying dnsmasq options.

> >>

> >> This series adds a dnsmasq xmlns namespace for <network>

> >> XML that allows passing option strings directly to the

> >> generated dnsmasq config file. It will allow motivated

> >> users to work around libvirt until those types of RFEs

> >> are properly implemented.

> > 

> > 

> > This all looks like a reasonable facsimile of the qemu:commandline

> > stuff, and it worked in my tests (including not creating any problems

> > with all the existing networks I have on my test system).

> > 

> > 

> > My one reservation would be that it will tend to discourage adding

> > *supported* methods of configuring things that people will instead use

> > this backdoor to implement. But on the other hand, it makes it possible

> > to do new things without needing to wait for an officially supported

> > method (which could take a very long time, or simply never happen, as

> > we've seen).

> > 

> > 

> > (Actually I for some reason thought we already *had* support for the

> > specific example you used - CNAME records. I guess I had lumped it in

> > with SRV and TXT records in my memory. It really should be

> > straightforward to do, and should still be done, but that shouldn't stop

> > this patch series from going in).

> > 

> > 

> > This is for the entire series:

> > 

> > 

> > Reviewed-by: Laine Stump <laine@laine.org>

> 

> Thanks, I've pushed this now.

> 

> Regarding the bigger point, I think it's worth considering whether we

> should aim to expose every requested dnsmasq option as official XML or

> not. We effectively have one network driver; there's an impl for vbox

> and esx but they seem very basic. It doesn't look like we are going to

> have another backend impl any time soon.


I wouldn't rule it out. I can't remember where it was, but a few months
ago I had a discussion with some folks precisely about replacing dnsmasq
with new daemon(s). Primarily the purpose would getting a more secure
solution modern solution written in a memory safe language.

> Unless the requested option has some specific reason to be represented

> in libvirt XML, like if another part of libvirt may need/want to

> programmatically act on that data for some reason, maybe it's okay to

> say that dnsmasq passthrough is the solution. Some examples might be

> 

> * dhcp-option: https://bugzilla.redhat.com/show_bug.cgi?id=666556

> * auth-zone: https://bugzilla.redhat.com/show_bug.cgi?id=1690943

> * This bug has a lot of mentioned options:

> https://bugzilla.redhat.com/show_bug.cgi?id=824573


Most of the stuff across these bugs is not really dnsmasq specific.
It would be applicable to any DNS/DHCP service, so its just a matter
of expressing it sensibly in the XML, so you're not tied to dnsmasq
specific syntax.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Laine Stump July 18, 2019, 3:08 p.m. UTC | #4
On 7/18/19 4:59 AM, Daniel P. Berrangé wrote:
> On Wed, Jul 17, 2019 at 05:38:51PM -0400, Cole Robinson wrote:
>> On 7/17/19 12:49 PM, Laine Stump wrote:
>>> On 7/14/19 8:03 PM, Cole Robinson wrote:
>>>> There's several unresolved RFEs for the <network> bridge
>>>> driver that are essentially requests to add XML wrappers
>>>> for underlying dnsmasq options.
>>>>
>>>> This series adds a dnsmasq xmlns namespace for <network>
>>>> XML that allows passing option strings directly to the
>>>> generated dnsmasq config file. It will allow motivated
>>>> users to work around libvirt until those types of RFEs
>>>> are properly implemented.
>>>
>>> This all looks like a reasonable facsimile of the qemu:commandline
>>> stuff, and it worked in my tests (including not creating any problems
>>> with all the existing networks I have on my test system).
>>>
>>>
>>> My one reservation would be that it will tend to discourage adding
>>> *supported* methods of configuring things that people will instead use
>>> this backdoor to implement. But on the other hand, it makes it possible
>>> to do new things without needing to wait for an officially supported
>>> method (which could take a very long time, or simply never happen, as
>>> we've seen).
>>>
>>>
>>> (Actually I for some reason thought we already *had* support for the
>>> specific example you used - CNAME records. I guess I had lumped it in
>>> with SRV and TXT records in my memory. It really should be
>>> straightforward to do, and should still be done, but that shouldn't stop
>>> this patch series from going in).
>>>
>>>
>>> This is for the entire series:
>>>
>>>
>>> Reviewed-by: Laine Stump <laine@laine.org>
>> Thanks, I've pushed this now.
>>
>> Regarding the bigger point, I think it's worth considering whether we
>> should aim to expose every requested dnsmasq option as official XML or
>> not.


Definitely not; there's a lot of things that maybe only one person would 
ever do, or it's just too difficult and pointless to try and abstract 
the config in a way that retains full functionality while being 
implementation agnostic (that's what stopped the dhcp options stuff in 
its tracks - the original patches had a problem with escaped characters 
or something, but once you started down the rabbit hole there was just 
no end).


But if something is commonly used then it's better to have a 
straightforward way to do it so that everybody does it the same way, and 
we don't end up with all sorts of obscure questions because someone 
follows some loosely connected bad advice they found on a random page on 
the internet and their setup becomes completely broken.


>> We effectively have one network driver; there's an impl for vbox
>> and esx but they seem very basic. It doesn't look like we are going to
>> have another backend impl any time soon.
> I wouldn't rule it out. I can't remember where it was, but a few months
> ago I had a discussion with some folks precisely about replacing dnsmasq
> with new daemon(s). Primarily the purpose would getting a more secure
> solution modern solution written in a memory safe language.
>
>> Unless the requested option has some specific reason to be represented
>> in libvirt XML, like if another part of libvirt may need/want to
>> programmatically act on that data for some reason, maybe it's okay to
>> say that dnsmasq passthrough is the solution. Some examples might be
>>
>> * dhcp-option: https://bugzilla.redhat.com/show_bug.cgi?id=666556
>> * auth-zone: https://bugzilla.redhat.com/show_bug.cgi?id=1690943
>> * This bug has a lot of mentioned options:
>> https://bugzilla.redhat.com/show_bug.cgi?id=824573
> Most of the stuff across these bugs is not really dnsmasq specific.
> It would be applicable to any DNS/DHCP service, so its just a matter
> of expressing it sensibly in the XML, so you're not tied to dnsmasq
> specific syntax.


Yeah, in the past we may have been trying too hard to make the XML 
backend-agnostic. And even for domain XML, it's never been the case that 
the exact same XML would work unmodified for both Xen and qemu, for 
example. It definitely is good to work *towards* that though; makes it 
less of a task in the case that a change in backend does happen (for 
example, what Dan mentioned above).


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list