-----BEGIN PGP SIGNED MESSAGE-----
On 23.07.2016 12:09, Maciej Delmanowski wrote:
In the IRC channel, ganto brought up an idea to remove the
'debops.ifupdown' role from the common playbook and move it to a separate
play, activated by an Ansible group. After thinking about it I agree, but
we wanted to hear an opinion of the community about this as well.
The 'debops.ifupdown' role came to be because I wanted most of my hosts to
be automatically configured with network bridges, in case that the host
would be used to run virtual machines and/or containers, which is a very
common practice these days. By default it automatically sets up one or two
network bridges, depending on the host type and number of physical network
This has two big advantages for a server:
- after running the common playbook, the host is ready to deploy virtual
machines or containers with their network interfaces connected to the same
networks as the host itself
- in cases where physical network connections are inverted, say 'eth0' is a
private network and 'eth1' is a public network, know sets of bridge names
can make this switch agnostic to the rest of the software - just set the
correct public and private network interfaces and run the 'debops.ifudown'
role to have it configure the bridges in a known layout. This advantage
can be show for example with the 'debops.ferm' role, were you could define
different rules for public and private interfaces based on the network
bridge names and have them correctly filter traffic.
Unfortunately, the current situation with 'debops.ifupdown' managing
interfaces by default in the 'common' playbook has its drawbacks as well:
- host and interface detection isn't perfect and can sometimes fail. This
is important especially for new users, who might not expect the network
layout to change, or host going offline for unknown reasons due to wrong
configuration being guessed by the role.
- some host configurations don't let you manage the network interfaces
from inside of the host itself - for example restricted Docker containers,
and similar. Some of these configurations can be detected by checking
POSIX capabilities, but that doesn't work in all cases. In such setups, the
user is forced to disable 'debops.ifupdown' entirely via inventory
variable, in which case the whole role becomes useless to him/her.
- if an user plans to use 'systemd-networkd' to manage the host
networking, 'debops.ifupdown' might interfere, forcing the user to disable
it, in which case it becomes just a dead weight in the 'common' playbook.
Therefore, I'm considering removing the 'debops.ifupdown' from the
'common' playbook. The role is used much less frequently by other roles
than say, 'debops.ferm' is, so the changes to the playbook behaviour in the
short run. On the other hand, other roles that depend on known state of
network interfaces might need to be modified to use local facts which
'debops.ifudown' will need to create to indicate what interface is the
public/private one (for example 'debops.dhcpd' might need this information
to disable the daemon on correct network interfaces).
To enable the 'debops.ifupdown' role to manage interfaces, you will need
to add a host to an inventory group. This will make a few things easier to
do - some of the automatic host detection code could be safely removed,
therefore the role will be easier to manage.
I haven't tested the effects yet, the change won't be done for sometime as
I would like to finish a different switch first - removing Postfix from
the 'common' role and replacing it with nullmailer. So if you are
interested, there's time to voice your opinion and sway me in the other
I think moving `debops.ifupdown` out of the common playbook makes sense. More
experienced DebOps users can easily enable it when needed/wanted and newcomers
can concentrate on other things first when trying it out.
Live long and prosper
Robin `ypid` Schneider
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----