Bug#930367: cloud.debian.org: vagrant images: use systemd-networkd for virtualbox provider

2019-06-23 Thread Nicolas Quiniou-Briand

Emmanuel,

Just for a better understanding, if your patch is accepted in Buster, 
can you just tell me what will be the networking behavior for virtualbox 
boxes ?


Thanks.
--
Nicolas Quiniou-Briand
Jabber/XMPP : n...@azyx.fr



Bug#930367: cloud.debian.org: vagrant images: use systemd-networkd for virtualbox provider

2019-06-15 Thread Antonio Terceiro
On Fri, Jun 14, 2019 at 02:42:23PM +0200, Emmanuel Kasper wrote:
> Le 11/06/2019 à 17:07, Antonio Terceiro a écrit :
> > Control: retitle -1 vagrant images: network setup in libvirt images are not 
> > consistent with Debian defaults
> > 
> > On Tue, Jun 11, 2019 at 04:15:12PM +0200, Nicolas Quiniou-Briand wrote:
> >> Package: cloud.debian.org
> >> Severity: normal
> >>
> >> Dear Maintainer,
> >>
> >> I noticed a difference between providers for the same box
> >> (debian/stretch64):
> >>
> >> * with libvirt provider, `systemd-networkd` service is enabled and started
> >> after first boot of VM.
> >>
> >> * with virtualbox provider, `systemd-networkd`
> >> service is disabled and stopped after first boot of VM.
> >>
> >> It will be better to have only one way to manage network for the same image
> >> with different providers.
> > 
> > actually, the correct fix would be to make the libvirt images use the
> > same setup as virtualbox (which is the same as a regular Debian install
> > created by the Debian installer).
> > 
> 
> vmdeboostrap is unable to create a networked VM using ifudown, ( the
> /etc/network/interfaces handler and Debian default) as configuring the
> VM with ifupdown would require a non predictable network interface like
> eth0 to work on all VMs config. [1]
> 
> Unfortunately, non predictable network interfaces are only set in
> vmdebootstrap for systemd-networkd,
> 
> The attached (untested) patch should fix the bug in vmdeboostrap.
> The patch adds non predictable network interface when using ifupdown,
> and lets the Debian default of having predictable when using systemd.
> 
> Unfortunately again :) vmdeboostrap itself is more or less EOL, its
> maintainer Lars required the package to be removed from the archive.

since a few things couldn't migrate to something else in time (e.g.
Debian Live images), in the end vmdebootstrap has been kept in buster.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910201

So, you could maybe get that patch in Buster, if you convince whoever
adopted it and the release team, and make sure that doesn't break the
live images. But it has to be really soon.

Unfortunately I'm neck deep in other things, and won't be able to help
with it.

> Then longterm fix would be to switch to fai-diskimage like other cloud
> images are doing. I am planning to do this for the Debian 11 release.

yes please


signature.asc
Description: PGP signature


Bug#930367: cloud.debian.org: vagrant images: use systemd-networkd for virtualbox provider

2019-06-14 Thread Emmanuel Kasper
Le 11/06/2019 à 17:07, Antonio Terceiro a écrit :
> Control: retitle -1 vagrant images: network setup in libvirt images are not 
> consistent with Debian defaults
> 
> On Tue, Jun 11, 2019 at 04:15:12PM +0200, Nicolas Quiniou-Briand wrote:
>> Package: cloud.debian.org
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> I noticed a difference between providers for the same box
>> (debian/stretch64):
>>
>> * with libvirt provider, `systemd-networkd` service is enabled and started
>> after first boot of VM.
>>
>> * with virtualbox provider, `systemd-networkd`
>> service is disabled and stopped after first boot of VM.
>>
>> It will be better to have only one way to manage network for the same image
>> with different providers.
> 
> actually, the correct fix would be to make the libvirt images use the
> same setup as virtualbox (which is the same as a regular Debian install
> created by the Debian installer).
> 

vmdeboostrap is unable to create a networked VM using ifudown, ( the
/etc/network/interfaces handler and Debian default) as configuring the
VM with ifupdown would require a non predictable network interface like
eth0 to work on all VMs config. [1]

Unfortunately, non predictable network interfaces are only set in
vmdebootstrap for systemd-networkd,

The attached (untested) patch should fix the bug in vmdeboostrap.
The patch adds non predictable network interface when using ifupdown,
and lets the Debian default of having predictable when using systemd.

Unfortunately again :) vmdeboostrap itself is more or less EOL, its
maintainer Lars required the package to be removed from the archive.

Then longterm fix would be to switch to fai-diskimage like other cloud
images are doing. I am planning to do this for the Debian 11 release.


[1] Otherwise you would end up with en0p3s1 on one VM or en4p1s6 as NIC
name when booting on different VM.

[2] As systemd-networkd can cope with a globbing like e*, which will
match all network interfaces, persistent named or not, and does not need
to have predictable interfaces disabled.
-- 
You know an upstream is nice when they even accept m68k patches.
  - John Paul Adrian Glaubitz, Debian OpenJDK maintainer
diff --git a/bin/vmdebootstrap b/bin/vmdebootstrap
index d9a697d..29eb81a 100755
--- a/bin/vmdebootstrap
+++ b/bin/vmdebootstrap
@@ -322,7 +322,7 @@ class VmDebootstrap(cliapp.Application):  # pylint: 
disable=too-many-public-meth
 network.setup_wheezy_networking(rootdir)
 else:
 if self.settings['systemd-networkd']:
-network.systemd_support(rootdir)
+network.enable_systemd_networkd(rootdir)
 network.enable_systemd_resolved(rootdir)
 else:
 # /etc/network/interfaces.d/
diff --git a/vmdebootstrap/network.py b/vmdebootstrap/network.py
index 25f3155..1d3cfc6 100644
--- a/vmdebootstrap/network.py
+++ b/vmdebootstrap/network.py
@@ -62,15 +62,7 @@ class Networking(Base):
 def setup_networking(self, rootdir):
 self._write_network_interfaces(
 rootdir, 'source-directory /etc/network/interfaces.d\n')
-
-def systemd_support(self, rootdir):
-"""
-Handle the systemd-networkd setting
-"""
-if self.settings['systemd-networkd']:
-self.enable_systemd_networkd(rootdir)
-else:
-self.mask_udev_predictable_rules(rootdir)
+self.mask_udev_predictable_rules(rootdir)
 
 def mask_udev_predictable_rules(self, rootdir):
 """


Bug#930367: cloud.debian.org: vagrant images: use systemd-networkd for virtualbox provider

2019-06-11 Thread Antonio Terceiro
Control: retitle -1 vagrant images: network setup in libvirt images are not 
consistent with Debian defaults

On Tue, Jun 11, 2019 at 04:15:12PM +0200, Nicolas Quiniou-Briand wrote:
> Package: cloud.debian.org
> Severity: normal
> 
> Dear Maintainer,
> 
> I noticed a difference between providers for the same box
> (debian/stretch64):
> 
> * with libvirt provider, `systemd-networkd` service is enabled and started
> after first boot of VM.
> 
> * with virtualbox provider, `systemd-networkd`
> service is disabled and stopped after first boot of VM.
> 
> It will be better to have only one way to manage network for the same image
> with different providers.

actually, the correct fix would be to make the libvirt images use the
same setup as virtualbox (which is the same as a regular Debian install
created by the Debian installer).


signature.asc
Description: PGP signature


Bug#930367: cloud.debian.org: vagrant images: use systemd-networkd for virtualbox provider

2019-06-11 Thread Nicolas Quiniou-Briand

Package: cloud.debian.org
Severity: normal

Dear Maintainer,

I noticed a difference between providers for the same box 
(debian/stretch64):


* with libvirt provider, `systemd-networkd` service is enabled and started
after first boot of VM.

* with virtualbox provider, `systemd-networkd`
service is disabled and stopped after first boot of VM.

It will be better to have only one way to manage network for the same 
image with different providers.