openvswitch-switch package postinst modifies existing configuration
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Neutron Open vSwitch Charm |
Invalid
|
Undecided
|
Unassigned | ||
Ubuntu Cloud Archive |
Fix Released
|
High
|
Unassigned | ||
Mitaka |
Fix Released
|
High
|
Unassigned | ||
Newton |
Fix Released
|
High
|
Unassigned | ||
Ocata |
Fix Released
|
High
|
Unassigned | ||
Pike |
Fix Released
|
High
|
Unassigned | ||
openvswitch |
Invalid
|
Undecided
|
|||
openvswitch (Ubuntu) |
Fix Released
|
High
|
Frode Nordahl | ||
Xenial |
Fix Released
|
High
|
Frode Nordahl | ||
Zesty |
Fix Released
|
High
|
Frode Nordahl | ||
Artful |
Fix Released
|
High
|
Frode Nordahl |
Bug Description
[Impact]
* When using OpenvSwitch in a modeled or configuration managed environment unmotivated changes to configuration files like /etc/default/
* Restarting the openvswitch-switch service impacts datapath and should be avoided. Any future updates or security updates to this package will cause problems for existing users and I believe the package in the stable release should be updated because of this.
* I also believe having a package change existing configuration files to be in conflict with best practices set out in the config files section of the Debian Policy.
* The proposed fix addresses the issue by removing the processing of /etc/default/
[Test Case]
* apt install openvswitch-switch
* edit /etc/default/
* apt remove openvswitch-switch
* stat /etc/default/
* Observe that your modified configuration file remains
* apt install openvswitch-switch
* stat /etc/default/
* Observe that the openvswitch-switch package has added comments to your modified configuration file
* Repeat these steps with the proposed fix and observe that the configuration file is no longer modified by the package postinst script.
[Regression Potential]
* The current postinst script aims at adding non-existing sections of the template to the default file in /etc. These sections are commented out and have no effect on the running service.
* End users will find any new configuration options in the template
[Original Bug Description]
Similar to, but slightly different from bug 1712444, we have found the upgrade of the openvswitch-switch package by unattended-upgrade (or otherwise) will trigger the service restart of openvswitch-switch within the neutron-openvswitch charm if the config-changed hook is called.
While this is a reasonable behavior based on an assumption that if the /etc/default/
Would it be possible to have a config-flag to disable the charm's ability to restart the openvswitch-switch service outside of the install hook to avoid automated network outages due to package upgrades?
Elsewise, is there a way to serialize the resulting restarts in such a way that only one member of the neutron-openvswitch application/service is restarting at a time along with a buffer to allow for high availability applications to failover and fail back and not be afflicted by multiple nodes' switches being restarted simultaneously.
Changed in openvswitch (Ubuntu): | |
status: | Triaged → Confirmed |
summary: |
- openvswitch-switch package upgrade overwrites /etc/default/openvswitch- - switch + openvswitch-switch package postinst modifies existing configuration |
tags: | added: uosci |
Changed in openvswitch (Ubuntu Zesty): | |
status: | New → Triaged |
Changed in openvswitch (Ubuntu Xenial): | |
status: | New → Triaged |
Changed in openvswitch (Ubuntu Zesty): | |
importance: | Undecided → High |
Changed in openvswitch (Ubuntu Xenial): | |
importance: | Undecided → High |
Changed in openvswitch (Ubuntu Artful): | |
status: | Confirmed → Triaged |
Changed in openvswitch: | |
status: | New → Invalid |
description: | updated |
tags: | added: sts-sru-needed |
Changed in openvswitch (Ubuntu Zesty): | |
assignee: | nobody → Frode Nordahl (fnordahl) |
Changed in openvswitch (Ubuntu Xenial): | |
assignee: | nobody → Frode Nordahl (fnordahl) |
On Fri, Oct 13, 2017 at 05:00:16PM -0000, Drew Freiberger wrote:
[...]
> Elsewise, is there a way to serialize the resulting restarts in such a
> way that only one member of the neutron-openvswitch application/service
> is restarting at a time along with a buffer to allow for high
> availability applications to failover and fail back and not be afflicted
> by multiple nodes' switches being restarted simultaneously.
This seems to be cover what you are asking here: https:/ /review. openstack. org/#/c/ 504310/