| 2022-10-14 03:37:35 |
Haw Loeung |
bug |
|
|
added bug |
| 2022-10-14 03:37:47 |
Haw Loeung |
bug |
|
|
added subscriber The Canonical Sysadmins |
| 2022-10-14 03:39:32 |
Haw Loeung |
description |
Hi,
With charms supporting multiple series, it doesn't make sense to me anymore to constraint 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 "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? |
Hi,
With charms supporting multiple series, it doesn't make sense to me anymore to constraint 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 "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. |
|
| 2022-10-14 07:27:29 |
Harry Pidcock |
juju: importance |
Undecided |
High |
|
| 2022-10-14 07:27:29 |
Harry Pidcock |
juju: status |
New |
Triaged |
|
| 2022-10-14 07:27:29 |
Harry Pidcock |
juju: milestone |
|
3.1.0 |
|
| 2022-10-14 08:23:24 |
Haw Loeung |
description |
Hi,
With charms supporting multiple series, it doesn't make sense to me anymore to constraint 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 "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. |
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 "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. |
|
| 2022-10-14 08:24:18 |
Haw Loeung |
description |
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 "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. |
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. |
|
| 2023-01-20 06:38:02 |
Canonical Juju QA Bot |
juju: milestone |
3.1-beta1 |
3.1-rc1 |
|
| 2023-01-23 09:41:47 |
Vitaly Antonenko |
tags |
|
charm series |
|
| 2023-01-24 14:05:05 |
Canonical Juju QA Bot |
juju: milestone |
3.1-rc1 |
3.1-rc2 |
|
| 2023-02-01 05:28:45 |
Canonical Juju QA Bot |
juju: milestone |
3.1-rc2 |
3.1-rc3 |
|
| 2024-01-16 17:43:02 |
Jorge RodrÃguez |
bug |
|
|
added subscriber Jorge RodrÃguez |
