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?

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.

On Mon, Oct 5, 2020 at 5:02 PM David Ames <david.ames@canonical.com> wrote:

FWIW, I have used sym links in a couple of charms [0] [1]. This seems
like a perfectly rational thing to do. I suspect it could be leveraged
even further as @Xav Paice suggests.

@Alex Kavanagh, I think this is a separate issue from mojo, as this
primarily pertains to Zaza tests. Also, the build process removes the
sym-links and creates separate files for us in a built charm.

[0] https://github.com/openstack/charm-mysql-innodb-cluster/tree/master/src/tests/bundles
[1] https://github.com/openstack-charmers/charm-ceph-benchmarking/tree/master/tests/bundles

--
David Ames

On Mon, Oct 5, 2020 at 4:07 AM Chris MacNaughton
<chris.macnaughton@canonical.com> wrote:
>
>
> > I think I remember that a conscious decision was made to avoid using
> > symlinks for the bundles due to the hell that openstack-mojo-specs
> > descended into? Liam may want to wade in on this?
> >
> Broadly, this is one of the reasons I proposed submitting a review of a
> single charm to be a practical example of what this would look like, and
> how complex it would be. It should also help us, as a project, identify
> if the repetition is enough that symlinks, or refactoring the library,
> would be worthwhile.
>
> Chris
>