Comment 9 for bug 1435283

Preserving the order so the first address is on top is one option, but the real problem is we're not acting consistently. After a charm runs $ unit-get private-address (or public-address) the address we return should be the same every time (assuming it's still there - e.g. if it was on a NIC which is now down, we should pick another one valid I guess). So there might be a good idea to add the "address we picked initially for private/public" metadata to the address in state. It has to be backwards-compatible though in both how stored in mongo addresses are interpreted and passed over the API. I did suggest to add a "global-key-like" tag to the address.Value field (e.g. "1.2.3.4#defaut" where the "#default" is a "tag" of sorts saying "this address is the one to use for its respective scope" w.r.t. which one is considered public, local-cloud, etc.).