| === akhavr1 is now known as akhavr | ||
| rick_h | wallyworld: ping around? | 19:58 |
|---|---|---|
| wallyworld | rick_h: hey | 20:11 |
| rick_h | wallyworld: nvm, I'm a moron. I was all focused on adding network-get to charm helpers I miss read that what I really need in the charm is relation-get | 20:11 |
| rick_h | wallyworld: so I got it all working and realized...hmm...the address I need isn't in this new network-get output | 20:11 |
| rick_h | wallyworld: updating to use relation-get now instead and will test out. Is that backward compatible with pre-2.3? | 20:12 |
| wallyworld | rick_h: relation-get still contains the old private-address value, yes | 20:12 |
| wallyworld | juju 2.3 will put in the new stuff also | 20:12 |
| rick_h | wallyworld: gotcha, so 2.3 is ingress-address and if that's not there fall back to private-address for backwards compat | 20:13 |
| wallyworld | yep | 20:13 |
| wallyworld | so you want to get what the remote unit's address is? | 20:13 |
| wallyworld | as opposed to using network-get to see the local unit's info? | 20:13 |
| wallyworld | rick_h: I ask because i thought the prometheus charm was using unit-get | 20:14 |
| wallyworld | hence the replacement for that is network-get | 20:14 |
| rick_h | wallyworld: it's using: hostname = relation_data.get('hostname') | 20:15 |
| rick_h | wallyworld: so I'm updating that line to build the newer address details | 20:15 |
| wallyworld | ok. i also recall unit-get being used | 20:15 |
| wallyworld | somewhere in a hook | 20:15 |
| rick_h | wallyworld: yes, in the address of prometheus itself | 20:15 |
| wallyworld | that should use network-get | 20:15 |
| rick_h | wallyworld: so that'll need to be setup so that it's listening/sending the right info to things that relate to it (e.g. grafana) | 20:15 |
| rick_h | wallyworld: right | 20:16 |
| wallyworld | so your network-get charm helper work is still needed | 20:16 |
| rick_h | wallyworld: so the work on network-get is not in vain, but atm just trying to get the telegraf->prometheus part working and that's the the relation-get update | 20:16 |
| wallyworld | ok | 20:17 |
| rick_h | wallyworld: anyway, basically I freaked out and ping'd and now I'm unfreaked out and on to working more. sorry for the noise | 20:17 |
| wallyworld | rick_h: no worries, sorry i didn't see stuff earlier, was in sessions etc | 20:18 |
| rick_h | wallyworld: completely figured as much. All good | 20:18 |
| wallyworld | am excited to see this working | 20:18 |
| rick_h | bdx: is as well. He was asking about it and is doing some demo material for work around it | 20:18 |
| wallyworld | great | 20:19 |
| rick_h | wallyworld: bdx has some questions on what gets returned when used in a vpc and such | 20:19 |
| rick_h | so once I get the charms behaving I'll ask him to do some vpc testing and make sure things are looking cool | 20:19 |
| wallyworld | ok. i can't tell you off hand what is returned. cmr just reads the public address recorded against the machine | 20:19 |
| wallyworld | whatever that is | 20:20 |
| rick_h | wallyworld: right, so there might be bugs filed because if he binds against vpc specific networks he won't want his stuff on the public network. His vpc is making sure different models can speak to each other | 20:20 |
| wallyworld | right. that's not something we support yet | 20:20 |
| rick_h | ok, good to know. bdx will love to test it out when it does :) | 20:21 |
| wallyworld | not sure how much time we'll have this cycle | 20:21 |
| wallyworld | we were told to cut scope to just support public addresses for now | 20:21 |
| rick_h | k | 20:21 |
| wallyworld | if there's a driver to do the next step, we can look at what we can do | 20:22 |
| rick_h | well still, it'll be good to have bugs on the books with repro steps and users wanting things | 20:22 |
| wallyworld | exactly | 20:22 |
| bdx | theres a driver! | 20:23 |
| bdx | me | 20:24 |
| bdx | the public address stuff ..... I don't even have a use for (not that others won't) | 20:25 |
| bdx | but like | 20:25 |
| zeestrat | Count me in for use cases with non-public addresses. | 20:26 |
| bdx | even the MAAS <-> AWS stuff I have planned all happens over VPG to our vpc | 20:26 |
| bdx | so the MAAS instances have no idea the AWS instances aren't local | 20:26 |
| bdx | well ok | 20:27 |
| bdx | so the majority of the aws instances I will be connecting to don't have public ips | 20:27 |
| bdx | they are all in private NAT subnets that dont get public ips | 20:27 |
| bdx | so, I don't think I even have to worry about it for the most part | 20:28 |
| bdx | because juju will just think (for aws instances in NAT subnets) the public ip is the private ip, because it will be the only ip | 20:28 |
| bdx | wallyworld, rick_h: from what I can see, I will encounter an issue when I want to make a CMR from an instance with both public and private ips (AWS instance in IGW subnet that gets public ip auto assigned) | 20:30 |
| bdx | but even then, I can just use "--via" right? | 20:31 |
| rick_h | bdx: yea, we'll have to play with it and put together notes on what's there what's next. | 20:31 |
| bdx | kk | 20:31 |
| rick_h | bdx: so you can on the relate command, but what the charm reads from the hooks... | 20:31 |
| bdx | ahh | 20:31 |
| rick_h | bdx: it might be that it'll be more maas/openstack friendly at the start. JAAS has some work to support it as well. | 20:31 |
| wallyworld | i think if there's no public address recorded it will fall back to private | 20:32 |
| wallyworld | so long as those are routable between models it should work | 20:32 |
| bdx | wallyworld: I can deal with that | 20:32 |
| bdx | awesome | 20:32 |
| wallyworld | *should* | 20:32 |
| wallyworld | :-) | 20:32 |
| bdx | wallyworld, rick_h, jpk: having an issue with standard lxd deploys to instances using aws provider and 2.3beta2, getting http://paste.ubuntu.com/25715842/ | 20:41 |
| bdx | ahhhh | 20:41 |
| bdx | AWS isn't a supported provider for the default FAN type probably I bet | 20:42 |
| bdx | per the release notes "On AWS, FAN works out of the box" | 20:44 |
| bdx | :( | 20:44 |
| wallyworld | bdx: sorry, in meeting, will respond soon if i can | 20:45 |
| bdx | np | 20:45 |
| bdx | thx | 20:45 |
| jam | bdx: please file a bug, I have the feeling it is a problem with the interaction between a defined space and fan configuration | 20:58 |
| jam | since 'common-nat' isn't a space name that Juju would have set up | 20:58 |
| jam | so I'm guessing you added it | 20:58 |
| bdx | jam: yeah | 21:25 |
| bdx | https://bugs.launchpad.net/juju/+bug/1722661 | 21:25 |
| mup | Bug #1722661: FAN - unable to setup network <juju:New> <https://launchpad.net/bugs/1722661> | 21:25 |
| jam | bdx: are you trying to test out fan, or are you wanting to just have a container behind nat? | 21:42 |
| bdx | jam: I was just taking 2.3 for a test drive .... thought I would start out with testing what happens when I type in something familiar | 21:43 |
| bdx | :) | 21:43 |
| bdx | I like what I see for the non-space-constraint instance though | 21:46 |
| bdx | jam: I wonder if it has anything to do with the fact that my common-nat space is a nat subnet | 21:46 |
| jam | bdx: sounds possible | 21:46 |
| bdx | the ips that the containers get from the provider are basically elastic ips right? | 21:47 |
| bdx | I see | 21:48 |
| bdx | so, this is a limitation then? | 21:48 |
| bdx | the limitation being that provider type FAN networking for AWS is limited to subnets with routing tables that use an IGW | 21:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!