Merge lp://qastaging/~stub/charm-helpers/bug-1557769-ensure-ip-address into lp://qastaging/charm-helpers

Proposed by Stuart Bishop
Status: Needs review
Proposed branch: lp://qastaging/~stub/charm-helpers/bug-1557769-ensure-ip-address
Merge into: lp://qastaging/charm-helpers
Diff against target: 131 lines (+56/-9)
3 files modified
Makefile (+2/-2)
charmhelpers/core/hookenv.py (+19/-2)
tests/core/test_hookenv.py (+35/-5)
To merge this branch: bzr merge lp://qastaging/~stub/charm-helpers/bug-1557769-ensure-ip-address
Reviewer Review Type Date Requested Status
charmers Pending
Review via email: mp+289128@code.qastaging.launchpad.net

Description of the change

Juju 1.25.4 seems to be again returning names in some situations where we expect IP addresses. Fix this, even though it might be considered a Juju regression.

To post a comment you must log in.
Revision history for this message
Cory Johns (johnsca) wrote :

From my understanding, private-address was never guaranteed to return an IP and in fact almost always returns some form of host name, meaning this function was always poorly named. I believe it depends on the provider what is actually returned.

For the big data charms (and originally for CloudFoundry), we use a similar helper[1] to force it to IPs, but that doesn't support IPv6 as yours does. We also ran into at least one instance where the "host name" returned wasn't resolvable and the IP was part of the host name string and had to be parsed out. My point is just that there a lot of corner cases in what should be a simple function.

It would be ideal if Juju handled this for us and had a private-ip field as well.

[1]: https://github.com/juju-solutions/jujubigdata/blob/master/jujubigdata/utils.py#L404

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

I'm leaving it up to the juju-core bug squad to decide if this is a juju-core bug or not :) I'm fixing it here for old versions of Juju, and because I need the fix right now for a production deployment. We can open feature requests if they decline to accept Bug #1557769, and if they get implemented, update this function to use it when it is available.

I think we should ignore the case where what is returned by unit-info private-address is not even a resolvable name - that is certainly a provider bug (and one I don't think exists anywhere any more?). If getaddrinfo can't decode it (an unparsable or unresolvable name), it is useless to charms and their software and I think I'm doing the right thing by raising a ValueError rather than, say, attempting to munge it or pass it on through for the charm to choke on it. Call sites can of course catch the ValueError and deal with it if they really need to.

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

It seems that juju-core has accepted the change in 1.25.4 under some providers as a regression.

Even if not, we should fix charm-helpers to return a consistent value across providers.

The Cassandra charm under 1.25.4 or later has been broken for a few months now under some providers. I'll try to get a release out with a forked charm-helpers next week since it is griefing one of our projects, but i would be nice to get this landed upstream in charm-helpers.

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

This is still occurring under Juju 2.1, so I'd like to get this landed in charm-helpers.

Unmerged revisions

550. By Stuart Bishop

Ensure IP addresses are returned by methods claiming to return IP addresses

549. By Stuart Bishop

Missing dependencies

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.

Subscribers

People subscribed via source and target branches