private-address returns name, not ip

Bug #1557769 reported by Stuart Bishop
20
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Charm Helpers
Critical
Stuart Bishop
PostgreSQL Charm
Critical
Stuart Bishop
Telegraf Charm
High
Wouter van Bommel
juju
High
Unassigned
juju-core
High
Unassigned
1.25
High
Unassigned
cassandra (Juju Charms Collection)
Critical
Stuart Bishop

Bug Description

Under Juju 1.25.4:

$ juju run --unit=dse/0 'unit-get private-address'
sudice.internal

Previously this returned an IP address.

This breaks charm-helpers, where hookenv.unit_private_ip() is now returning a name.

This breaks at least two charms using hookenv.unit_private_ip() to work around Bug #1328269 (Cassandra, and I think I cargo culted that code from Rabbit). Cassandra services upgraded to 1.25.4 will not survive a restart.

Related branches

Stuart Bishop (stub)
Changed in charm-helpers:
status: New → In Progress
importance: Undecided → Critical
assignee: nobody → Stuart Bishop (stub)
Stuart Bishop (stub)
Changed in cassandra (Juju Charms Collection):
status: New → In Progress
importance: Undecided → Critical
assignee: nobody → Stuart Bishop (stub)
Changed in juju-core:
status: New → Triaged
importance: Undecided → High
milestone: none → 1.25.5
Changed in juju-core:
milestone: 1.25.5 → 1.25.6
Stuart Bishop (stub)
Changed in cassandra (Juju Charms Collection):
status: In Progress → Fix Released
Revision history for this message
Stuart Bishop (stub) wrote :

Charms will retrieve this value from relations (relation-get private-address) and may fail when they are handed a name rather than an IP address (arbitrary depending on provider). This can't be worked around in charm helpers

Changed in charm-helpers:
status: In Progress → Fix Released
status: Fix Released → In Progress
Curtis Hovey (sinzui)
Changed in juju-core:
milestone: 1.25.6 → 1.25.7
Changed in juju-core:
status: Triaged → Invalid
milestone: 1.25.7 → none
Changed in juju:
status: New → Triaged
importance: Undecided → High
milestone: none → 2.0.0
Revision history for this message
Alexis Bruemmer (alexis-bruemmer) wrote :

Stuart,

This is working locally for me on juju 2.0 (ie I can run "juju run --unit=<unitname>/0 'unit-get private-address'" for charms in my deployment and it returns an ip. Can you please re-open with exact recreate steps if this is still an issue for you.

Thanks!

Changed in juju:
status: Triaged → Incomplete
Revision history for this message
Richard Harding (rharding) wrote :

This is a known issue with the Juju tooling around networking. We are working to enable specific tools for address vs hostname. It'll all be pulled into the network get functionality and you'll be able to get just the hostname or just the IP address. That work though won't be completed until Juju 2.1.

Changed in juju:
milestone: 2.0.0 → 2.1.0
Revision history for this message
Stuart Bishop (stub) wrote :

This bug was opened for 1.25.4, which I found had changed behaviour from 1.25.3 with certain providers. It hasn't broken under 2.0 yet afaik.

description: updated
Revision history for this message
Stuart Bishop (stub) wrote :

I'm setting this to wishlist for 'juju'. While the behavior isn't broken at the moment, it is already targeted to 2.1.0 and having things documented as returning an IP address rather than a name is what is required here. So providers can't return rubbish and claim 'works as designed'. If not wishlist, it is invalid.

Changed in juju:
status: Incomplete → Triaged
Revision history for this message
Anastasia (anastasia-macmood) wrote :

I have also added a documentation issue https://github.com/juju/docs/issues/1409 to clarify private-address behavior and return value.

summary: - private-address returns name, not ip, under 1.25.4
+ private-address returns name, not ip
Revision history for this message
Anastasia (anastasia-macmood) wrote :

@Stuart,
I think that the only provider that exhibited this behavior was MAAS. Because there were considerable differences between MAAS 1.9 and 2.0, I am guessing that you are not seeing this behavior with Juju 2.0 is because you are running against MAAS 2.0.
Could you please clarify which provider, including versions, was causing you issues?

I suspect that the docs and Juju are correct in saying that we expected an IP to be returned as private-address value. So there may not be anything to do here.

Changed in juju:
status: Triaged → Incomplete
milestone: 2.1.0 → none
Revision history for this message
Stuart Bishop (stub) wrote :

This still happens under 2.1.1 with the manual provider. I have production installations where monitoring is failing because the charm is receiving a DNS name instead of an address from 'unit-get private-address'. Confirmed with 'juju run --unit foo/0 'unit-get private-address'

Changed in juju:
status: Incomplete → New
tags: added: canonical-is
Revision history for this message
Stuart Bishop (stub) wrote :

PostgreSQL lag monitoring is failing in the telegraf charm. The database query is failing because hostname is being send instead of a valid IP address.

Changed in telegraf-charm:
importance: Undecided → High
status: New → Triaged
Revision history for this message
Stuart Bishop (stub) wrote :

The PostgreSQL charm is failing, similarly to telegraf, in that queries to the pg_stat_replication table require an IP address and we are attempting to use a DNS name.

Changed in postgresql-charm:
importance: Undecided → Critical
status: New → Triaged
Stuart Bishop (stub)
Changed in postgresql-charm:
assignee: nobody → Stuart Bishop (stub)
status: Triaged → In Progress
Stuart Bishop (stub)
Changed in postgresql-charm:
status: In Progress → Fix Released
Tim Penhey (thumper)
Changed in juju:
status: New → Triaged
tags: added: manual-provider network
Revision history for this message
Stuart Bishop (stub) wrote :

With modern juju, network-get will return actual addresses for the addresses.

Changed in juju:
status: Triaged → Fix Released
Changed in charm-telegraf:
assignee: nobody → Wouter van Bommel (woutervb)
status: Triaged → In Progress
Changed in charm-telegraf:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.