principal and subordinate applications' series must match

[Haw Loeung]

Hi,

With charms supporting multiple series, it doesn't make sense to me anymore to constrain them based on the series used to deploy the primary. For example, in an environment I have, I have an application deployed as "Focal" and the telegraf subordinate as "Focal".

I've now deployed a new application using "Jammy" but I can't relate the telegraf subordinate to that as it gives me:

| $ juju add-relation stunnel telegraf
| ERROR cannot add relation "telegraf:juju-info stunnel:juju-info": principal and subordinate applications' series must match

The telegraf charm supports both series and knows what to do. We've been deploying new telegraf instances as telegraf-$series to work around this but perhaps we can remove this constraint within Juju?

Having subordinates not tied to series allows us to reduce duplication with the various stock subordinates we deploy - landscape-client, telegraf, ubuntu-advantage, nrpe, userdir-ldap, and autocert to name a few.

[Haw Loeung (hloeung)]

The charms collection has a list of series supported. Maybe it can use that for now to determine rather than match primary and subordinate series?

[Guillermo Gonzalez (verterok)]

Hi,

I might have hit a different incarnation of this bug, just in slightly different way.
Subordinate was filebeat charm, which recently got all series removed from the metadata.yaml: https://github.com/juju-solutions/layer-filebeat/commit/4e3a7156581d3967cc916cadd113db12ad0469ce#diff-d186204ea7abb85bbadd9d94ab29d5bcefcc43d6a0ed06015e98a71b2f099423
After that change juju refuses to deploy relate the subordinate to any principal not matching the series where the subordinate was originally deployed.

I filed an issue in layer-filebeat charm to get the series list fixed. Also got a custom build of the charm with series specified to unblock us.