proxy config is rendered to /lib/systemd/system/docker.service which breaks non-interactive apt upgrades
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Docker Subordinate Charm |
Fix Released
|
High
|
Joseph Borg |
Bug Description
If the kubernetes-worker charm is deployed behind a corporate firewall that only allows access via http(s) proxy's. This has to be configured in the model.
If these settings change, then the systemd file for docker (/lib/systemd/
Environment=
Environment=
Environment=
But the service is not restarted.
What is expected is that a file would have been created in /etc/systemd/
[Service]
Environment=
Environment=
Environment=
Obviously the service also needs to restart if this is changed
The current approach (modifying the file under /lib/systemd) has as problem that it will block any non interactive upgrade, as a file is changed that is part of the original package.
tags: | added: bootstack |
description: | updated |
Changed in charm-docker: | |
assignee: | nobody → Joseph Borg (joeborg) |
status: | Triaged → In Progress |
Changed in charm-docker: | |
status: | In Progress → Fix Committed |
tags: | removed: review-needed |
Changed in charm-docker: | |
milestone: | none → 1.20 |
Changed in charm-docker: | |
status: | Fix Committed → Fix Released |
Docker is now installed by the docker subordinate charm, which appears to correctly restart the service after re-rendering the systemd file[1].
> The current approach (modifying the file under /lib/systemd) has as problem that it will block any non interactive upgrade, as a file is changed that is part of the original package.
Makes sense. I'll leave this issue open so we can address that at least.
[1]: https:/ /github. com/charmed- kubernetes/ charm-docker/ blob/5caed3afbe 55e11779209e0bc 517dbf217c3daaa /reactive/ docker. py#L206- L211