default network space

[James Beedy]

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('') 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

Re: upgrade-charm hook

[Merlijn Sebrechts]

We're continuing the discussion about this in the charms.reactive issue
tracker: https://github.com/juju-solutions/charms.reactive/issues/87

Feel free to start hacking on this!

2017-10-05 18:37 GMT+02:00 sheila miguez :

> I'd like something like this.
>
> The layer-snap's upgrade-hook cycle calls code[1] that checks for a
> non-zero resource, and then checks whether that resource has changed. I bet
> many charmers do this, and it would be useful to have a decorator that does
> it for us.
>
>
> [1] https://github.com/stub42/layer-snap/blob/master/lib/
> charms/layer/snap.py#L53
>
>
>
>
> On Tue, Sep 26, 2017 at 9:51 AM, James Beedy  wrote:
>
>> That totally does! This sounds like a great path forward that would allow
>> us to eventually migrate away from having 'upgrade-charm' fire when a
>> resource is attached, while maintaining backward compat for the charms that
>> use it until its deprecated.
>>
>> Well  I didn't mean to just imply that things should change to this ^
>> way, but it seems sensible. Possibly we could have more of a conversation
>> around this?
>>
>> ~James
>>
>>
>>
>> On Tue, Sep 26, 2017 at 12:41 AM, Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> Does a `resource.changed` flag address your needs? That should be
>>> possible to implement in charms.reactive, I think.
>>>
>>> 2017-09-24 17:53 GMT+02:00 James Beedy :
>>>
 How do people feel about splitting the upgrade-charm hook into multiple
 hooks to facilitate better resource management?

 What I'm thinking would be super helpful would be to have the
 upgrade-charm hook still active for charm upgrades, and have separate hooks
 or flags that would indicate resource upgrades.

 I'm thinking something like:

 'juju attach myapp myresource=myresource.file'

 Would cause the 'upgrade-resource-myresource'  hook to become active on
 instances of 'myapp'.

 I feel that having this affinity from resource ->
 resource-upgrade- hook would be a huge win for resource
 management.

 Thoughts?




 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
 an/listinfo/juju-dev

>>>
>>>
>>
>> --
>> Juju mailing list
>> j...@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
>
> --
> she...@pobox.com
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev