Hi folks
TL;DR; I want to rename a yaml/json attribute in network-get output. I want to
see if any charmers would find this to be an issue. IIANM, we don't (yet) have a
tool to easily scrape the charm store to see what charms use network-get
directly. Charm helpers calls network-get with the --primary-address flag and
this will continue to work as before [1].
[1] --primary-address will be deprecated in Juju 2.3; --bind-address should be
used instead.
* If you see a reason not to rename the network-get yaml/json "info" attribute,
now is the time to speak up *
There's already been internal discussion with some key charmers about the new
content for network-get. But given we're looking to change output, it's time to
circulate more widely.
The network-get hook tool has been evolving over the past few cycles as a
replacement for the unit-get hook tool. The tool is not yet quite finished; as
of now in Juju 2.x releases, the following is supported:
$ network-get "binding" --primary-address
$ network-get "binding"
Without the --primary-address flag, the output is a yaml printout of all the
link layer devices and their addresses on the machine, relevant to the specified
binding according to the space to which it is associated. It's also possible to
ask for json.
Here's an example output:
$ network-get "binding"
info:
- macaddress: "00:11:22:33:44:00"
interfacename: eth0
addresses:
- address: 10.10.0.23
cidr: 10.10.0.0/24
- address: 192.168.1.111
cidr: 192.168.1.0/24
- macaddress: "00:11:22:33:44:11"
interfacename: eth1
addresses:
- address: 10.10.1.23
cidr: 10.10.1.0/24
- address: 192.168.2.111
cidr: 192.168.2.0/24
$ network-get "binding" --primary-address
10.10.0.23
Problem 1.
The json output is not consistent with the yaml. json uses "network-info"
instead of "info" as the attribute tag name.
Problem 2.
The attribute tag name itself.
Instead of "info" or "network-info", I want to rename to "bind-addresses". Or
maybe even "local-addresses"?. Here's why.
There's 3 key pieces of address information a charm needs to know, for either
the local unit and/or the remote unit:
1. what address to bind to (to listen on)
2. what address to advertise for incoming connections (ingress)
3. what subnets outbound traffic will originate from (egress)
Note: the following applies to the develop branch only. 2.x is missing all of
this new stuff.
For the remote unit, this information is in relation data as these attributes:
- ingress-address
- egress-subnets
For the local unit, network-get is the tool to use to find out. I want to rename
the "info" attribute to better reflect the semantics of what the data represents
as well as fix the yaml/json mismatch.
Here's an example
bind-addresses:
- macaddress: "00:11:22:33:44:00"
interfacename: eth0
addresses:
- address: 10.10.0.23
cidr: 10.10.0.0/24
- address: 192.168.1.111
cidr: 192.168.1.0/24
- macaddress: "00:11:22:33:44:11"
interfacename: eth1
addresses:
- address: 10.10.1.23
cidr: 10.10.1.0/24
- address: 192.168.2.111
cidr: 192.168.2.0/24
egress-subnets:
- 192.168.1.0/8
- 10.0.0.0/8
ingress-addresses:
- 100.1.2.3
You can also ask for individual values
$ network-get "binding" --bind-address
10.10.0.23
$ network-get "binding" --ingress-address
100.1.2.3
Cross Model Relations
A key driver for this work is cross model relations. When called in a relation
context, or with the -r arg to specify a relation id, the ingress and egress
information provided by network-get is adjusted so that it is correct for the
relation. The charm itself remains agnostic to whether it is a cross model
relation or not; Juju does all the work. But suffice to say, charms should
evolve to use the new semantics of network-get so that they are cross model
relations compatible. As is the case now with charm helpers and how it falls
back to unit-get for older versions of Juju, this new work will only be
available in 2.3 onwards, so charm helpers will need to deal with that.
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
