Re: [PATCH 6/7] network: turn on autoaddr in default network
On 8/7/24 1:45 PM, Daniel P. Berrangé wrote:
On Wed, Aug 07, 2024 at 01:16:02PM -0400, Laine Stump wrote:
> With autoaddr enabled, the subnet to be used for the default network
> will be verified/changed at the time the network starts.
>
> Signed-off-by: Laine Stump <laine(a)redhat.com>
> ---
> src/network/default.xml.in | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/network/default.xml.in b/src/network/default.xml.in
> index 08a3632eb6..a01c6d30ae 100644
> --- a/src/network/default.xml.in
> +++ b/src/network/default.xml.in
> @@ -2,7 +2,7 @@
> <name>default</name>
> <bridge name='virbr0'/>
> <forward/>
> - <ip address='192.168.122.1' netmask='255.255.255.0'>
> + <ip autoaddr='yes' address='192.168.122.1'
netmask='255.255.255.0'>
> <dhcp>
> <range start='192.168.122.2' end='192.168.122.254'/>
> </dhcp>
What I find unsettling is that we're providing an address + netmask
here, along with a DHCP range, but there's no guarantee any of these
are within the start+end addresses in network.conf
The code removes the network part of any existing dhcp range, static
host, or bootpserver, and replaces that with the network part of the
newly chosen network, which puts them into the same subnet, so actually
it is guaranteed.
While I agree that it might be unusual for someone to have static host
addresses configured in a network where they wanted to use autoaddr,
it's not difficult to support, and makes the handling consistent with
the way that the network's IP address, and also the DHCP range and bootp
server addresses are handled - basically every IP address associated
with the network is moved to the new subnet.
I'm thinking that perhaps autoaddr='yes' should be
mutually exclusive
with existence of an explicit address + DHCP range. ie only permit
<ip autoaddr='yes'>
<dhcp/>
</ip>
on the basis that if someone wants explicit control over the DHCP
range, then they probably shouldn't be relying on auto-addr usage.
That simplifies it, but would require removing the code that saves the
current chosen subnet (so that it can be tried first when the network is
next started), making it more likely that addresses would change each
time the network is started. I see you've brought up exactly that topic
on your response to Patch 7/7 :-)