Merge ~aluria/charm-telegraf:remote-unit-name into ~telegraf-charmers/charm-telegraf:master
Proposed by
Alvaro Uria
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Alvaro Uria | ||||
Approved revision: | 2920829b8dc4671c0685c86d575a639833ec699c | ||||
Merged at revision: | 9bdf8979ff4edda16f34fc293e65bf65091f71e1 | ||||
Proposed branch: | ~aluria/charm-telegraf:remote-unit-name | ||||
Merge into: | ~telegraf-charmers/charm-telegraf:master | ||||
Diff against target: |
21 lines (+1/-9) 1 file modified
reactive/telegraf.py (+1/-9) |
||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Peter Sabaini (community) | Approve | ||
James Hebden (community) | Needs Information | ||
Review via email: mp+336901@code.launchpad.net |
To post a comment you must log in.
The reason for added the code you are removing was that when deployed to units which have multiple networks, we had observed the returned private address may not be routable between the telegraf unit and the prometheus server is was related to as a target. The below code fixed that by being sympathetic to the primary network address of the space the relation was bound to, rather than using the units private IP address.
This is the 4th case which we also need to test against - when the prometheus target relation is bound to a different space in order to gain access to a server only accessible on a network other than the unit's detected private address - for example when deployed alongside a Ceph monitor where the storage access network may be picked up for the private-address.