group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1723480@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package openvswitch - 2.8.0-0ubuntu2

---------------
openvswitch (2.8.0-0ubuntu2) artful; urgency=medium

  [ James Page ]
  * d/p/s390x-stp-timeout.patch: Increase STP sync wait time for
    'STP - flush the fdb and mdb when topology changed' test as this
    reliable takes longer than 36 seconds on s390x (LP: #1722799).

  [ Frode Nordahl ]
  * d/openvswitch-switch.postinst: Do not modify
    /etc/default/openvswitch-switch as this file is now managed
    as a configuration file by dpkg (LP: #1723480).

 -- James Page <james.page@xxxxxxxxxx>  Thu, 19 Oct 2017 11:04:37 +0100

** Changed in: openvswitch (Ubuntu Artful)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1723480

Title:
  openvswitch-switch package postinst modifies existing configuration

Status in OpenStack neutron-openvswitch charm:
  Invalid
Status in Ubuntu Cloud Archive:
  Triaged
Status in Ubuntu Cloud Archive mitaka series:
  Triaged
Status in Ubuntu Cloud Archive newton series:
  Triaged
Status in Ubuntu Cloud Archive ocata series:
  Triaged
Status in Ubuntu Cloud Archive pike series:
  Triaged
Status in openvswitch:
  Invalid
Status in openvswitch package in Ubuntu:
  Fix Released
Status in openvswitch source package in Xenial:
  Fix Committed
Status in openvswitch source package in Zesty:
  Fix Committed
Status in openvswitch source package in Artful:
  Fix Released

Bug description:
  [Impact] 
   * When using OpenvSwitch in a modeled or configuration managed environment unmotivated changes to configuration files like  /etc/default/openvswitch-switch will lead unnecessary service restarts on future events in a deployment.

   * 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/openvsiwtch-switch from the postinst script. The template
  for this processing is installed in
  /usr/share/openvswitch/switch/default.template should the user want to
  view comments added there in future updates.

  [Test Case]

   * apt install openvswitch-switch
   * edit /etc/default/openvswitch-switch, removing one of the commented out sections
   * apt remove openvswitch-switch
   * stat /etc/default/openvswitch-switch
   * Observe that your modified configuration file remains
   * apt install openvswitch-switch
   * stat /etc/default/openvswitch-switch
   * 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/openvswitch-switch file changes due to upgrade and the
  charm resets it to the charm-configured version of the file, we should
  want to restart the service to be on the latest code.  However, the
  restart of the service causes between 6-12 seconds of network outage
  for the tenant VMs utilizing OVS.

  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-neutron-openvswitch/+bug/1723480/+subscriptions