debconf for bridge configuration is confusing and too complicated

It turns out that if I answer "no" to the first question, it only asks me about using an existing bridge. I leave the default lxcbr0, then I get networking back in containers.

So *if* lxcbr0 exists, I suggest using that by default in lxd -- I can't imagine a situation where you would *not* want to use that bridge and instead the non-working unconfigured network by default. And if lxcbr0 does not exist, could debconf have a mode to just set up lxdbr0 with default values like we used to have for lxcbr0? And maybe allow customization with -plow and followup questions if you say "no" to "configure the default LXD bridge"?

Hmm, the fact that you had lxcbr0 was probably a bug in a previous migration script, it should have been lxdbr0.

We can't use lxcbr0 because on most systems lxc1 will be marked for auto-removal after upgrading to the lxd version which brings lxdbr0, so at configuration time the bridge would still be there, but 10min later, not so much.

We also can't default on any subnet, that's the whole point of lxdbr0, defaulting on a subnet has been breaking user network in the past and is exactly why we were told not to do that anymore. We do suggest a subnet in all those questions though, typing in those values will get you working networking.

As for the first debconf question, it was a request from https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1566764 but it sounds like you got the updated prompt already.

Now that I read the initial debconf note three times I think I know what the difference between "yes" and "no" is. But "Do you want LXD to setup a network bridge for you?" does not encourage me to select "no", and the default is "yes" too.

But "yes" leads you into this trap of having to specify all those gory details manually.

OTOH, saying "no" and using lxcbr0 works on my laptop, but in a fresh cloud image the question about which existing bridge to use defaults to "lxdbr0", and if I select that nothing happens because lxdbr0 does not actually exist. But there is no error message in debconf either to say "this bridge does not exist".

May I suggest to structure this differently? The first question should be something like "Do you want to set up a bridge for LXD with default parameters? If you say "no" here, you can enter the IP configuration of the bridge manually", default to "yes", and do what lxcbr0 always used to. There can even be some checks if a 10.0.3.0/24 network already exists, and it can pick 10.0.4.0/24. And only if you select the non-default "no" you can then enter all those gory details. These should still have default values for what lxcbr0 used to have, so that you have something to start from. Particularly it should generate a valid IPv6 address.

We can't do what you suggest because LXD is pre-installed in a bunch of images and picking a default subnet there is going to break networking.

> We also can't default on any subnet, that's the whole point of lxdbr0, defaulting on a subnet has been breaking user network in the past

How is that, OOI? postinst/debconf/etc. should certainly check if there's an existing 10.0.3.x network already, and not set up a default lxdbr0 then (or use a different IP). I. e. were these breakages because of conflicts with an existing network in that range, or something else?

> We do suggest a subnet in all those questions though, typing in those values will get you working networking.

Could the input lines at least be pre-filled with those, instead of/in addition to showing them in the text?

I'll try to find a way to get debconf to empty the bridge name when switching from a LXD configured bridge to you providing one. The same debconf variable is used for both which is why you saw lxdbr0 pre-seeded in there, but I should be able to detect that case and have it emptied.

> We can't do what you suggest because LXD is pre-installed in a bunch of images and picking a default subnet there is going to break networking.

No, no, I don't mean on package install time, but at the time you run "dpkg-reconfigure lxd" . I understand that/why we can't set up the bridge by default, I'd just like to make it humanly possible to actually *do* configure a working bridge without being a network pro and having to type tons of IP addresses.

We could add a "seed with default values" option for both IPv4 and IPv6 which sets everything to the suggested values with a pretty big warning that if you are somehow using those subnets, this will break your network.

That would mean two more questions though (one for IPv4, one for IPv6) as we really should still show all the values to the user so they can check that they are sane and have a chance to change them.

> with a pretty big warning that if you are somehow using those subnets, this will break your network.

But the .config script can tell if there's an existing interface/network with that subnet?

> That would mean two more questions though

Why two new ones? I think we should repurpose the current first question and just not ask about all the network details if you say "yes" and go with the default bridge config (assuming that 10.0.3.x isn't taken yet). That would be one question for pretty much all cases, and one note about "you need to configure the bridge yourself because 10.0.3.x is already being used" plus the existing details question in the 1% corner case.

> we really should still show all the values to the user so they can check that they are sane and have a chance to change them.

OK, if you want to do that, then I don't see which additional questions you want to ask at all?

You are right that we don't actually have to ask the user to pre-fill some random values. We should however show a warning explaining that those values may conflict with their network and that they should take a close look at them.

So basically the change I would do is: When selecting Yes to the "enable IPv4" or "enable IPv6" questions, and no subnet was already set on the bridge, show the warning message, then pick a random local subnet (RFC1918 for IPv4, local scope for IPv6) and set it. Then continue as usual which will show all the values to the user.

Detecting whether the subnet is in use locally is just broken, there is no way to know whether the subnet is used behind your router and doing IPv4 masking math from a shell script is near impossible so say if you have 10.0.0.0/17 routed, 10.0.3.0/24 is a very bad idea, but figuring that out is a pain. So I would rather we don't pretend to be smart and just be consistently random so people don't depend on us being smart 50% of the time.

Ok, so just had a pretty good chat with Martin, conclusion is that we will:
 - Make use of the debconf "seen" flag to check whether we are running interactively or not
 - If running interactively and no configuration was previously set, set both IPv4 and IPv6 to "yes"
 - Show a warning message to the user in both the IPv4 and IPv6 case telling them that a random subnet was picked for them and that if it's used somewhere on their network, they will need to change it to something else.
 - Show the user the pre-filled values.

The intent is that a user can just keep pressing enter in dpkg-reconfigure and they'll be getting working IPv4 and IPv6 connectivity. However a non-interactive clean package install WILL NOT pick any subnet and so will not risk breaking connectivity for the user.

When saying "random" above, we will make a best effort to pick something that's not already in use but make no promises at succeeding, so that's why we will keep referring to it as "random".

This bug was fixed in the package lxd - 2.0.0~rc9-0ubuntu3

---------------
lxd (2.0.0~rc9-0ubuntu3) xenial; urgency=medium

  * More lxdbr0 tweaks:
    - Generate a random IPv4 and IPv6 subnet and pre-fill the questions
      with it at interactive configuration time. (LP: #1567440)
    - Point users towards dpkg-reconfigure if lxd init can't be run.

 -- Stéphane Graber <email address hidden> Thu, 07 Apr 2016 15:26:33 -0400

Many thanks for fixing this! I filed bug 1567874 with a small leftover.