purging cloud-init doesn't remove its network configuration files

[Brent Baccala]

cloud-init creates /etc/netplan/50-cloud-init.yaml during its network configuration step.

However, "apt purge cloud-init" leaves this file intact.

I've seen this behavior on Ubuntu 18, 20, and 22.

I can always remove the file manually, but I'm left wondering what other files cloud-init might have left lingering around on the system.

Shouldn't a purge remove all files associated with a package?

[Brent Baccala (baccala)]

It also seems to leave build.info in /etc/cloud and doesn't remove that directory for that reason.

[Alberto Contreras (aciba)]

Reproduced with:

```sh
$ lxc launch ubuntu:jammy jj
$ lxc exec jj -- cloud-init status --wait
$ lxc exec jj -- cloud-init --version
/usr/bin/cloud-init 22.1-14-g2e17a0d6-0ubuntu1~22.04.5
$ lxc exec jj -- apt purge -y cloud-init
...
dpkg: warning: while removing cloud-init, directory '/etc/cloud' not empty so not removed
...
$ lxc exec jj -- ls /etc/cloud
build.info
$ lxc exec jj -- ls /etc/netplan
50-cloud-init.yaml
```

[Chad Smith (chad.smith)]

Thanks for the bug and triage folks.

While this is confirmed/known behavior, I don't think cloud-init should be automatically removing core configuration files that are not packaged by cloud-init's deb package especially if removal of those config files can have catastrophic consequences on the ability to connect to the system. If the networking service happens to be restarted outside of the perview of the admin purging the cloud-init package it would be very surprising for the unsuspecting admin to see the system drop.

Also we are aware of use-cases where folks may expect to use cloud-init once, and have attempted to remove cloud-init deb package after initial system configuration is correctly performed to ensure cloud-init no longer acts to reconfigure the system in the future.

While this use-case above is probably less desirable that just disabling cloud-init via `sudo touch /etc/cloud/cloud-init.disabled` it does allow image creators to reduce the overall size of their image if they are trying to generate customized images with cloud-init and remove cloud-init and any other dependencies on which cloud-init relies.

I'd prefer we avoid addressing this in packaging specifically, though we could grow this functionality in cloud-init clean to clean up network config artifacts generated by cloud-init. This would at least make it easier for your use-case of cleaning up all network config files that cloud-init generated on a system.

[Brent Baccala (baccala)]

I like the idea of working this into cloud-init clean.

My use case is that I use cloud-init to initially configure an instance
that will later be manually configured, so I don't want files lying around
that say things like "if you edit this file it will be overwritten on the
next boot" (I forget the exact wording) when that's not the case.

On Wed, Jun 1, 2022 at 7:50 PM Chad Smith <email address hidden>
wrote:

> Thanks for the bug and triage folks.
>
> While this is confirmed/known behavior, I don't think cloud-init should
> be automatically removing core configuration files that are not packaged
> by cloud-init's deb package especially if removal of those config files
> can have catastrophic consequences on the ability to connect to the
> system. If the networking service happens to be restarted outside of
> the perview of the admin purging the cloud-init package it would be very
> surprising for the unsuspecting admin to see the system drop.
>
> Also we are aware of use-cases where folks may expect to use cloud-init
> once, and have attempted to remove cloud-init deb package after initial
> system configuration is correctly performed to ensure cloud-init no
> longer acts to reconfigure the system in the future.
>
> While this use-case above is probably less desirable that just disabling
> cloud-init via `sudo touch /etc/cloud/cloud-init.disabled` it does allow
> image creators to reduce the overall size of their image if they are
> trying to generate customized images with cloud-init and remove cloud-
> init and any other dependencies on which cloud-init relies.
>
>
> I'd prefer we avoid addressing this in packaging specifically, though we
> could grow this functionality in cloud-init clean to clean up network
> config artifacts generated by cloud-init. This would at least make it
> easier for your use-case of cleaning up all network config files that
> cloud-init generated on a system.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1975744
>
> Title:
> purging cloud-init doesn't remove its network configuration files
>
> Status in cloud-init package in Ubuntu:
> Confirmed
>
> Bug description:
> cloud-init creates /etc/netplan/50-cloud-init.yaml during its network
> configuration step.
>
> However, "apt purge cloud-init" leaves this file intact.
>
> I've seen this behavior on Ubuntu 18, 20, and 22.
>
> I can always remove the file manually, but I'm left wondering what
> other files cloud-init might have left lingering around on the system.
>
> Shouldn't a purge remove all files associated with a package?
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1975744/+subscriptions
>
>