On Tue, Aug 18, 2020 at 08:46:01PM +0100, Adam D. Barratt wrote: > > https://github.com/canonical/cloud-init/commit/a6faf3acef02bd8cd4d46ac9efeebf24b3f21d81 > > I must admit that I'm slightly confused by that commit. > > The rationale is that the default file written by ifupdown uses > "source-directory", which will not read foo.cfg. However, the commit > that it points to clearly shows that the "source" directive is used > instead, and the manpage (as also pointed to by the cloud-init commit) > does not suggest that any such naming restriction applies to "source", > so far as I can see. I think the intent with that commit was to generate files that were usable with either "source" or "source-directory", which seems reasonable. Cloud-init doesn't control what's in /etc/network/interfaces, so it could be either type of source. There's also been some inconsistency between d-i, the cloud images, and ifupdown in terms of what's in the default /etc/network/interfaces, as described in the commit message for the following change (which doesn't actually appear to have made it into an ifupdown release): https://salsa.debian.org/debian/ifupdown/-/commit/caeefd14eb0f00aacdf4fb5927211851a31fb618 d-i uses "source /etc/network/interfaces.d/*", which will work for everybody (though I wonder if it'll pick up emacs backup files, or similar). So people using Debian systems installed via d-i might reasonably expect a ".cfg" file to be included. But most cloud images aren't build with d-i, so they'll likely get a "source-directory" line installed by ifupdown's postinst, or something installed by the cloud image generation tooling (which, in the cloud-team's case, also uses "source-directory"). So that probably explains why there's the desire to generate files compatible with "source-directory". > > This doesn't break Debian installs that had the default > > /etc/network/interfaces. But if it caused a regression for one > > provider, > > it probably caused regressions for others too. > > > > Not sure what the right approach in Debian is, here. Whether there > > should be a new bug filed against cloud-init in stable? > > If there's going to be a change proposed for the package in stable, > then there'll certainly need to be a new release.d.o bug, as this one > relates to a package that has already been included in a point release. > > My inclination is that this should probably be reverted in unstable, > and then that change backported to stable, as per my above analysis. I think cloud-init is probably doing the right thing, based on what d-i does and what ifupdown will do, if anybody ever uploads it. The cloud-init change actually *is* desirable based on what the buster ifupdown postinst generates, and for the interfaces file that the cloud-team installs. Prior to this change, cloud-init's generated files would be ignored on most installations, which is its own bug. It's only the ones that explicitly sourced the "*.cfg" files that would be impacted by this. So I don't think reverting is the right path forward. noah
Attachment:
signature.asc
Description: PGP signature