Charms in the Operator Framework get a default Kubernetes service port of 65535
Bug #1943786 reported by
Connor Chamberlain
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Confirmed
|
High
|
Unassigned |
Bug Description
Juju 2.9.7 fixed LP1922133 [0], which gave juju applications access to their cluster ip, rather than a set of individual unit addresses. When charms relate using cluster ip, no daemons can be found listening at <cluster-
This doesn't occur when relations provide unit addresses, as daemons can be found at <unit-ip>:<port>, as expected.
When looking at the kubernetes service descriptions, it appears that charms in the Operator Framework are assigned a port of 65535, which cannot be changed from within the charm.
[0] https:/
Edit: rewrote to encapsulate new information on this bug
Changed in juju: | |
status: | Incomplete → New |
Changed in juju: | |
status: | New → Confirmed |
description: | updated |
summary: |
- Connections fail when using a vip with a port in Charmed Operator - Framework + Charms in the Operator Framework get a default Kubernetes service port + of 65535 |
description: | updated |
To post a comment you must log in.
We need a little bit more context to understand what charms are being broken and what they are defining as "a vip".
Is this the Service definition for the overall application?
Is the bug that the daemon *should* be available at the "vip" but isn't being seen, or is it that the units want to be advertising the individual unit IPs rather than an overall application IP?