On Wed, 7 Oct 2020 at 02:37, Alex Kavanagh <alex.kavanagh@canonical.com> wrote:

Hi

So I'm not massively against the idea, but I would like to present some potential disadvantages for consideration:

I have to admit to not being keen to using symlinks for the functional test yaml files. My main objection is maintenance as new openstack and ubuntu releases occur and bundles are added and removed from the charm.

At present, without symlinks (apart from in the overlays), the bundle for an ubuntu-openstack version is a plain file. To remove a version, it is just deleted. If there are symlinks then the 'base.yaml' version represents the one that the charm starts with (say bionic-queens). And then bionic-rocky is a symlink (perhaps with an overlay) and bionic-stein is another symlink, etc. However, at some point in the future bionic-queens will eventually be removed. base.yaml is the 'bionic-queens'. So what is done with base.yaml? Do we make it 'focal-ussuri' and change all the overlays? Leave it as is? Have a new base for each Ubuntu LTS and work from that?

Take a quick look at https://review.opendev.org/#/c/756399/ for an example of what that might look like - to remove a bundle, e.g. the Trusty bundle, we could just rm trusty-mitaka.yaml (which we would do anyway) and rm overlays/trusty-mitaka.yaml.j2. Job done. If there's a bundle with no more symlinks pointing at it, that is something which could easily be missed though, and that's really up to folks that work with these charms on a daily basis (like yourself) to decide if that's an issue or not.

Whilst the current system isn't DRY, it does make it simple to see what's in a particular test bundle for a variation.

Having said all of the above, it is a bit of a pain to manage all the separate files as well, especially when there are changes across multiple versions of the tests.

Thanks
Alex.