search

debops / debops-playbooks

Ansible playbooks used by DebOps project
GNU General Public License v3.0
489 stars 88 forks source link

Stretch support status #368

Open bjornoss opened 7 years ago

bjornoss commented 7 years ago

Hi. Is there any known problems using the debops playbooks and roles with Debian Stretch? I have been using debops on Jessie for a while and like it a lot. I am about to install a new server and want to install Stretch because the release date is right around the corner. One role that I think is not ready for stretch is the lxc-role, is this correct? I want to create Stretch LXC-containers on a Stretch host. Thanks.

drybjed commented 7 years ago

Hello.

I think that at this point, all DebOps roles included in the common.yml playbook should work fine on Debian Stretch, since that's a common base for all hosts.

Apart from that, your mileage may vary. Some roles outside of the common playbook work very well with Stretch, for example debops.ifupdown. Some were not tested by me yet, but may work just fine. There are some roles like debops.postfix which weren't refreshed since Wheezy so they may work, but with an old configuration - some values might not be used anymore, or there's no support for newer features. You can look at the role status page to see which roles might be outdated.

Unfortunately, debops.lxc doesn't work correctly in Stretch the last time I checked - containers didn't start correctly. This might be an issue with an outdated lxc-debops template script, I'm not sure yet. The issue might also be related to this bug report in the debops.lxc role. Perhaps if you have experience with LXC containers, you could help solve that?

Anyway, I suggest that you create some disposable host based on Debian Stretch first and see if everything that you need works. If you can find fixes for possible issues, that's great, if not, a bug report will be enough. That should help others find out and fix bugs with DebOps on Stretch easier.

bjornoss commented 7 years ago

Thanks for the quick reply @drybjed I'll try to do an install and document and report any issues I find. Thanks again for the work you and the others are doing on project. Keep it up!

prahal commented 7 years ago

one noteworthy issue: debops.ifupdown marks bridge as allow-hotplug . Since ifupdown 8.0 these interfaces are not raised by the networking service.

ifupdown: networking.service fails to start allow-hotplug interfaces at boot

This breaks ifup-allow.boot.service from debops which depends on the interfaces systemd devices to be created networking.

NB: the new ifupdown networking.service is missing the code to bring up allow-hotplug interfaces. But the SysV init script still has this code so I expect this to be a bug of ifupdown 8.0 .

drybjed commented 7 years ago

@prahal The reason for this "issue" is a change in the ifup@.service systemd unit which binds the interface to a device unit generated automatically by udev. Bridges, tunnels, etc. don't have real device files, so the new ifup@.service does not work for them.

I've made some changes to the debops.ifupdown role in https://github.com/debops/ansible-ifupdown/pull/67 to accommodate this. The role creates a new systemd unit, iface@.service which is used for the "virtual" network interfaces and works as before. You could try this PR out and see if it works for you. It currently relies on changes in debops.ferm role defined in https://github.com/debops/ansible-ferm/pull/103 PR, so I would try that one as well.