Stretch support status

[bjornoss]

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]

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]

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]

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]

@prahal The reason for this "issue" is a change in the [email protected] 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 [email protected] does not work for them.

I've made some changes to the debops.ifupdown role in debops/ansible-ifupdown#67 to accommodate this. The role creates a new systemd unit, [email protected] 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 debops/ansible-ferm#103 PR, so I would try that one as well.