charm upgrade re-installs the python3-neutron-lbaas-dashboard package

[Lirim]

In bionic-rocky deployments when octavia-dashboard is related to openstack-dashboard doing a charm upgrade on openstack-dashboard the charm does not detect the presence of python3-octavia-dashboard and re-installs the python3-neutron-lbaas-dashboard thus causing a conflicting situation. This creates a reload loop effect on the dashboard when trying to access the loadbalancers view. The issue is easy reproducible by deploying openstack with octavia with versions of dashboard for example:

openstack-dashboard-293
octavia-dashboard-10

Once deployed trigger the charm upgrade on openstack-dashboard.

I reproduced this only on Rocky.Stein and Train releases seems not to be effected.Can we backport the fix to Rocky please.

[James Page (james-page)]

Offending line of code:

  https://opendev.org/openstack/charm-openstack-dashboard/src/branch/master/hooks/horizon_hooks.py#L156

Ideally `determine_packages` would ensure that python3-neutron-lbaas-dashboard is not installed if the octavia dashboard is installed as the two packages conflict in functionality.

[Alex Kavanagh (ajkavanagh)]

The situation is a little complicated, so I'll try and unpick it.

I *think* @Lirim also has charm-octavia-dashboard related to charm-openstack-dashboard. This, on install of charm-octavia-dashboard, installs the octavia python packages and removes the neutron-lbaas package:

class OctaviaDashboardCharm(charms_openstack.charm.OpenStackCharm):
    release = 'rocky'
    name = 'octavia-dashboard'
    packages = ['python3-octavia-dashboard']
    purge_packages = ['python3-neutron-lbaas-dashboard']
    python_version = 3
    adapters_class = charms_openstack.adapters.OpenStackRelationAdapters
    required_relations = ['dashboard']

    def install(self):
        # NOTE(fnordahl) purge_packages is only honoured by charms.openstack
        # on OpenStack upgrade, not first install.
        installed_purge_packages = list(
            set(self.purge_packages) -
            set(ch_fetch.filter_installed_packages(self.purge_packages))
        )
        if installed_purge_packages:
            ch_fetch.apt_purge(packages=installed_purge_packages,
                               fatal=True)
        super().install()

And that's it. e.g. if the principal charm is upgraded, then the package comes back. If the subordinate charm-octavia-dashboard is removed then the neutron-lbaas package doesn't magically come back.

The problem here, is that charm-openstack-dashboard doesn't actually have the correct information about what should be installed/purged.

Two possible approaches:

1. "Teach" charm-openstack-dashboard that if the charm-octavia-dashboard is related then it should adjust the "determine_packages" and "determine_purge_packages" functions appropriate; but that's fairly bad in that now functionality about 'what' to add/purge is split across two charms; it's also not extensible.

2. Add keys to the "dashboard-plugin" interface to allow a subordinate to indicate which packages should be added and which should be purged. Then charm-openstack-dashboard can install/purge the correct packages and upgrades add-relation/remove-relation will always do the right thing.

[James Page (james-page)]

I think I prefer #2 feels cleaner and properly interfaced

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.opendev.org/704574

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/704574
Committed: https://git.openstack.org/cgit/openstack/charm-openstack-dashboard/commit/?id=1e2515e13fb71c2ad5fe41251a581c9edf4f654b
Submitter: Zuul
Branch: master

commit 1e2515e13fb71c2ad5fe41251a581c9edf4f654b
Author: Alex Kavanagh <email address hidden>
Date: Tue Jan 28 14:02:25 2020 +0000

    Fix issue with plugins breaking packages

    The core issue is that the plugin had no way to signal to the
    principal charm what packages needed to be installed, and crucially,
    which conflicted with the packages that the plugin needs to operate.
    The referenced bug exhibits this issue in that, on install, a package
    is removed by the plugin, but the principal charm "doesn't know". Then
    on upgrade, the principal charm re-installs the package, and breaks
    the plugin.

    This patch allows the plugin to signal which packages it requires to
    operate via the dashboard-plugin interface. This ensures that when
    the openstack-dashboard charm upgrades it already "knows" what a
    plugin needs and acts accordingly. Equally, plugins can change their
    requirements and this patch allows them to update/remove/install
    packages as needed.

    The local_settings.py is already controlled by the principal, and this
    just shifts absolute control over packaging to the principal as well.
    The plugin charm's purpose is to indicate packages and config to the
    principal.

    Note. There should be no backwards compatibility issues with this
    change. If a plugin doesn't notify the principal of any packages then it
    won't take any action. This does mean that the openstack-charm should
    be upgrade prior to any plugins that gain this feature.

    Also disable disco test as disco is EOL.

    Change-Id: Ib3fc0b0525dabf70f45fd050af2ed05ba31129b9
    Related-Bug: #1853851