extra bindings and network model rework [Do not merge]

[PietroPasotti]

Fixes #87

This PR adds support for extra-bindings and reworks the network model to hopefully match Juju's more closely.

Issue: at the moment, if you want to add a Network, you always have to pass it in manually:

State(relations=[rel1, rel2], networks=[net1, net2])

While in fact the presence of an integration endpoint implies the presence of a network. So it feels like a charm should automatically have networks for each of its metadata-defined relation endpoints, regardless of whether the relations are 'alive' i.e. in State.

This PR changes the semantics and the type of State.networks: from an exhaustive list of the networks available to the charm being tested, to a binding name --> Network mapping: State.networks: Dict[str, Network]

The logic for network_get(binding:str, relation_id:Optional[int]) is also updated:

• if binding is an extra-binding, return State.networks[binding] if found, else a default network.
• if binding is the name of a relation endpoint (except subordinates, which do not get a network): return State.networks[binding] if found, else a default network.
• else, raise a fat exception

The idea is that now State.networks is an override mapping. The default network which you automatically get for each relation endpoint and extra-binding is not good enough, you can override it with a custom-defined one. For the most part, you will probably be fine using the default network, since in theory the charm should not have opinions about what IP it gets.

This is breaking, non-backwards-compatible, API change. Will release as v6.

[benhoyt]

Direction and new model seems good to me, thanks.

Just a few Python style comments.

[PietroPasotti]

@benhoyt @tonyandrewmeyer after some more investigation and a chat with Ian Booth which I quote below, I reworked again the interface bringing it API-wise somewhat close to where we started, but the semantics is more simple.

In a nutshell: from now on in Scenario, the charm will be able to do self.model.get_binding(X).network and get a default network (always the same one) if X is either a (peer or regular, NOT subordinate) relation endpoint, or an extra-binding defined in metadata.yaml.

If you want to override the network associated with a given endpoint or extra-binding, you can pass State(networks={X: Network(...)}), but I expect that to be a rather exotic use-case, because as Ian says, a charm should take whatever network it obtains as a given.

you can call network-get for any endpoint (called a binding when used with network-get). for that endpoint, juju will look at the model (has the endpoint been bound to a space, what NICs are there on the unit's host machine/container etc) and give back ip related pieces of info - binding address, ingress addresses, egress subnets. mac address, interface name etc
It doesn't matter if a relation has been formed yet (network-get works perfectly fine without supplying a relation) - the most important model aspect which influence the data you get is the space to which the endpoint is bound. where a relation can alter things is if it's a cross model relation - in that case juju will (all other things being equal) choose the most public address for the ingress address info. it's up to juju what the charm gets and the charm should not care about it at all. it's a model driven decision and it's up to the human to correctly set up the spaces and bind the endpoints to those to make things work. a charm should be totally agnostic to this.

[benhoyt]

That's quite a lot simpler -- nice!

[tonyandrewmeyer]

Looks great!