Hello all,
In case you haven't noticed, we now have a network_get() function available
in charmhelpers.core.hookenv (in master, not stable).
Just wanted to have a little discussion about how we are going to be
parsing network_get().
I first want to address the output of network_get() for an instance
deployed to the default vpc, no spaces constraint, and related to another
instance in another model also default vpc, no spaces constraint.
{'ingress-addresses': ['107.22.129.65'], 'bind-addresses': [{'addresses':
[{'cidr': '172.31.48.0/20', 'address': '172.31.51.59'}], 'interfacename':
'eth0', 'macaddress': '12:ba:53:58:9c:52'}, {'addresses': [{'cidr': '
252.48.0.0/12', 'address': '252.51.59.1'}], 'interfacename': 'fan-252',
'macaddress': '1e:a2:1e:96:ec:a2'}]}
The use case I have in mind here is such that I want to provide the private
network interface address via relation data in the provides.py of my
interface to the relating appliication.
This will be able to happen by calling
hookenv.network_get('<interface-name>') in the layer that provides the
interface in my charm, and passing the output to get the private interface
ip data, to then set that in the provides side of the relation.
Tracking?
The problem:
The problem is such that its not so straight forward to just get the
private address from the output of network_get().
As you can see above, I could filter for network interface name, but thats
about the least best way one could go about this.
Initially, I assumed the network_get() output would look different if you
had specified a spaces constraint when deploying your application, but the
output was similar to no spaces, e.g. spaces aren't listed in the output of
network_get().
All in all, what I'm after is a consistent way to grep either the space an
interface is bound to, or to get the public vs private address from the
output of network_get(), I think this is true for every provider just about
(ones that use spaces at least).
Instead of the dict above, I was thinking we might namespace the interfaces
inside of what type of interface they are to make it easier to decipher
when parsing the network_get().
My idea is a schema like the following:
{
'private-networks': {
'my-admin-space': {
'addresses': [
{
'cidr': '172.31.48.0/20',
'address': '172.31.51.59'
}
],
'interfacename': 'eth0',
'macaddress': '12:ba:53:58:9c:52'
}
'public-networks': {
'default': {
'addresses': [
{
'cidr': 'publicipaddress/32',
'address': 'publicipaddress'
}
],
}
'fan-networks': {
'fan-252': {
....
....
}
}
Where all interfaces bound to spaces are considered private addresses, and
with the assumption that if you don't specify a space constraint, your
private network interface is bound to the "default" space.
The key thing here is the schema structure grouping the interfaces bound to
spaces inside a private-networks level in the dict, and the introduction of
the fact that if you don't specify a space, you get an address bound to an
artificial "default" space.
I feel this would make things easier to consume, and interface to from a
developer standpoint.
Is this making sense? How do others feel?
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
