unit-get private-address could be made space aware

[John A Meinel]

It should be possible to use "juju deploy app --bind space" to give a preferred address to "unit-get private-address" that is not just one of the random addresses on each machine.

We should be able to line up the "default" binding from "--bind space" and use that space's address as the "private-address" for the unit.

We were avoiding spending too much time here, but feedback has been that charms are slow to adopt 'network-get', and coming up with a stable solution would be very helpful for the field.

This would allow most charms that only function in a single space to be configured by the operator.

We should also make sure "relation-get private-address" from the other side of a relation also sees the same IP address.

Implementation wise, it should be possible to make state.Unit.PrivateAddress() lookup the default binding for its application, and ask the state.Machine it is on for what address it has in that space.

[John A Meinel (jameinel)]

An interesting discussion point that came up on IRC with Ante, is that we might want to support:
 juju-private-address

As the official name of the values that we will put in "unit-get private-address". That should end up with a similar property because of how default-inheritance works. (If you set a default binding, that implicitly sets all named bindings.)

That would let you do:
  juju deploy app --bind foo,juju-private-address=bar

So all other bindings default to foo, but the specific not-otherwise-namespaced-to-a-binding would get you bar.

The particular use case is because nagios talks to nova-compute only via the 'juju-info' relation. Which doesn't otherwise have a binding associated with it. (we could potentially use juju-info as the binding name as well.)

[Patrizio Bassi (patrizio-bassi)]

i'm affected in a openstack environment too.

[Witold Krecicki (wpk)]

https://github.com/juju/juju/pull/7314