switching from external-network-id and external-port to data-port and bridge-mappings does not remove incorrect nics from bridges

On Wed, Dec 19, 2018 at 8:40 PM Xav Paice <email address hidden> wrote:

After some time, we discovered that these deprecated options should have
> been changed out, so we reset external-network-id, and external-port to
> default and configured all 4 gateway applications

The options should still work even though they are deprecated. If they are
in config.yaml and not removed they should still work. If they don't that's
a bug in the charm.

It would be nice to have a formal way to run a health check on config
options prior to charm upgrade. For example if ext-port had been removed in
a charm release you'd be able to run it and find out.

So the actual neutron-gateway code doesn't attempt to delete existing bridges. i.e. if any of the parameters changes a mapping, the old mappings are left with the changes to the config being added via ovs. The question is whether the neutron-gateway charm should enumerate what is currently configured in ovs (for example), see what the config is, diff that, and then take the appropriate action to remove bridge/port mappings that are no longer configured.

https://review.openstack.org/#/c/630290/

Having discussed this bug in the OpenStack team, we've come to the following conclusion:

"Re-write the config-changed hook to reflect the options

i.e. delete bridge mappings/ports that no longer exist and add port mappings that now do exist. This would mean that any additional configuration done directly on the unit (for example by installers to create networking situations that the charm config doesn't handle) would be deleted/broken on the next config-changed hook for any config item.

This ensures that the charm is in full control of the OVS bridges, and that any tinkering is transient and will potentially be scrubbed; OVS is sufficiently verbose in the data you can get to be able to manage this effectively - we could even add extra data to the ports we add so it makes it easier to discover what the charm did vs anything done outside of the charm operations."

Fix proposed to branch: master
Review: https://review.opendev.org/673849

Fix proposed to branch: master
Review: https://review.opendev.org/717074

To completely address the issue, I think work also needs to be done on the neutron-openvswitch charm for scenarios where neutron-gateway is not used.

https://opendev.org/openstack/charm-neutron-openvswitch/src/commit/677a31b95ecc261446b92fd2608c34f08061d6aa/config.yaml#L103-L114

Reviewed: https://review.opendev.org/717074
Committed: https://git.openstack.org/cgit/openstack/charm-neutron-gateway/commit/?id=bbc621edca348c2d0a9061bffb6d65f823b236c1
Submitter: Zuul
Branch: master

commit bbc621edca348c2d0a9061bffb6d65f823b236c1
Author: Aurelien Lourot <email address hidden>
Date: Mon Mar 30 13:19:07 2020 +0200

    Mark OVS bridges and ports as managed by charm-neutron-gateway

    This patchset updates the configure_ovs() function in
    hooks/neutron_utils.py such that ports and bridges in OVS are marked as
    being managed by this charm. This will allow us to clean up obsolete
    managed bridges and ports in a later patchset. (On configuration change
    new ports and bridges might be created and former ones might become
    obsolete.)

    This patchset also fully deprecates the 'ext-port' config option such
    that if both 'data-port' and 'ext-port' config options are set, the unit
    is blocked. The README and config.yaml are updated to reflect this
    change.

    This patchset also fixes and removes a few dead links.

    Relies on a charm-helpers version containing these patchsets:
    https://github.com/juju/charm-helpers/pull/443
    https://github.com/juju/charm-helpers/pull/447
    https://github.com/juju/charm-helpers/pull/449

    Related documentation:
    * Deployment guide / Upgrades / Known issues: https://review.opendev.org/630290
    * Release notes: https://review.opendev.org/742660

    Change-Id: I8b459135d131e16865de40ff3eae16ea3bc7195e
    Partial-Bug: #1809190

So a lot of work has been done on code related to this bug around the charm neutron code. Please could you indicate if it is still a problem? Setting to incomplete to get a reminder in 60 days. Thanks.

With the updated documentation and the various changes in the neutron code, I'm removing this from field-high. The bug will not expire due to the multiple tasks at this point in time, but if there continue to be issues here please reopen on the charm-neutron-gateway with appropriate logs and commentary.

I've opened a new bug that is related to this issue. lp#1915967

I feel the documentation update addresses the subject of this bug, but there's another bug after you've changed to data-port that updates to data-port mappings do not remove old data-port interfaces from the bridge before adding new bridge interfaces.

Marking ports/bridges as managed by us in charm-neutron-openvswitch (as it was done in charm-neutron-gateway) is now tracked under lp:1917025.

The actual removal of obsolete ports/bridges is now tracked under lp:1915967 as mentioned above. Closing this bug.

Change abandoned by "James Page <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/charm-neutron-gateway/+/673849
Reason: This review is > 12 weeks without comment and currently blocked by a core reviewer with a -2. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and contacting the reviewer with the -2 on this review to ensure you address their concerns.