Handle subordinates OpenStack upgrades better

[Corey Bryant]

Principal charms (well at least nova-compute) currently don't appear to have a way to tell a subordinate charm to do an openstack upgrade. Subordinate charms don't have openstack-origin config options to trigger an upgrade (which makes sense). So it seems the principal charm would need to trigger the subordinate to upgrade.

For nova-compute, here's how we currently handle subordinate package dependencies. We handle them in the nova-compute charm, which is awkward and not obvious. This is particularly an issue with the transition from queens->rocky where we switched from py2 to py3. But this code could still be error prone in future releases. See commit 32ef5b4c and 280c0d7d. I'd like to see if we can figure out a better way for principals to tell subordinates they need to upgrade and allow them to upgrade their own packages.

def determine_packages()
    ...
    if cmp_release >= 'rocky':
        packages = [p for p in packages if not p.startswith('python-')]
        packages.extend(PY3_PACKAGES)
        if filter_missing_packages(['python-ceilometer']):
            packages.append('python3-ceilometer')
        if filter_missing_packages(['python-neutron']):
            packages.append('python3-neutron')
        if filter_missing_packages(['python-neutron-fwaas']): # to be added for this bug
            packages.append('python3-neutron-fwaas') # to be added for this bug
        if virt_type == 'lxd':
            packages.append('python3-nova-lxd')

    return packages

[Edward Hope-Morley (hopem)]

This is particularly problematic when doing Q -> R and therefore py2 -> py3

[Edward Hope-Morley (hopem)]

Also applies to neutron-gateway - none of my neutron service got restarted

[Edward Hope-Morley (hopem)]

Ammendment to comment #2, some did some didn't, specifically neutron-dhcp-agent did not get restarted.

[Alex Kavanagh (ajkavanagh)]

I think a good way to achieve this is to place the openstack-origin in the container-scope relation to the subordinate and then the subordinate can choose whether to upgrade based on what the principal is doing. This would be backwards compatible, as older charms would ignore the extra key.

[Felipe Reyes (freyes)]

On Thu, 2019-12-05 at 10:59 +0000, Alex Kavanagh wrote:
> I think a good way to achieve this is to place the openstack-origin
> in
> the container-scope relation to the subordinate and then the
> subordinate
> can choose whether to upgrade based on what the principal is doing.
> This would be backwards compatible, as older charms would ignore the
> extra key.

if nova-compute have configured bionic-rocky, and neutron-openvswitch
configures bionic-queens or bionic-stein, what would be the behavior?,
the subordinate wouldn't own /etc/apt/sources.list.d/cloud-
archive.list, right?

[Alex Kavanagh (ajkavanagh)]

> the subordinate wouldn't own /etc/apt/sources.list.d/cloud-
archive.list, right?

Yes, I think you are correct. It was more about providing more context to the subordinate about what the principal is doing/has state, and also providing a trigger (via the relation hook) to allow the subordinate to take action. The idea of adding state/context to the container-scope relation is just (my) idea of being able to allow the subordinate to make better/more informed decisions of whether to do things.

There is an example in the openstack-dashboard charm set (principal/subordinate) where the subordinate installs and removes a package that the principal installed; however, the principal wasn't aware of it, and so on upgrade, re-installs the package and breaks the installation. This is because the separation of concerns around 'who owns what' wasn't clear and therefore unfortunately broke.

I tend to think that the principal charm should actually do all the installation of packages, rendering of templates, and starting/stopping services, and the subordinate should indicate what it needs installed, rendered, and start/stopped; obviously there are issues around this (due to timing or hooks, when things get installed, etc.) but it might make for a clearer and more understandable approach to what is happening with a set of principal/subordinate charms.