[06:03] <BlackDex> KingJ: no indeed. would be nice if there is something like a git/bzr hash somewhere
[06:07] <BlackDex> or better, a list of the charm versions and a link to the commit log :)
[09:34] <BlackDex> KingJ: I do see that some charms have a repo-info file, but most of them don't
[10:36] <KingJ> BlackDex: Ahh, shame
[10:42] <KingJ> When i'm using network spaces, is there a way to get Juju to configure the interfaces to reply on the same interface they received the packet on? When i'm trying to reach a charm outside the subnet and the charm has multiple interfaces, it doesn't seem to use the correct interface.
[10:52] <KingJ> Actually hm. Could be a haproxy issue. Basically, when I try and hit the keystone API from outside the network, some of the connections timeout. But i've got no problems curl'ing them inside any of the openstack subnets. Hrm.
[11:19] <BlackDex> KingJ: Are you using MAAS?
[11:19] <KingJ> BlackDex: Yes
[11:19] <BlackDex> Of so, please check the squid/maas-proxy logs
[11:20] <KingJ> Ah yeah, that's a point
[11:20] <BlackDex> i think some traffic is being routed through there
[11:20] <BlackDex> you need to add the subnet to the no-proxy
[11:20] <KingJ> I do have no-proxy configured but I wonder if it's being captured transparently
[11:21] <BlackDex> how have you configured it?
[11:21] <KingJ> In the Juju model config
[11:21] <BlackDex> with CIDR?
[11:21] <KingJ> Yeah
[11:21] <BlackDex> i think that won't work
[11:21] <BlackDex> haha
[11:21] <BlackDex> you have to add every ip
[11:21] <KingJ> http-proxy/https-proxy aren't set, only apt-http(s)-proxy and no-proxy
[11:21] <BlackDex> well, that should not be a problem then
[11:22] <BlackDex> but better check the proxy log of maas if it still want to go through the proxy
[11:22] <KingJ> And just checking the Squid access logs, not seeing any hits (MaaS proxy disabled)
[14:59] <BlackDex> hmm
[20:57] <BlackDex> KingJ: is that netwerk where you are comming from know to the receiving end? If not, is the default gateway correctly configured? Sounds like a routing issue
[20:58] <KingJ> Default gateway is configured correctly, but each interface has a default gateway defined.
[20:58] <KingJ> I'm somewhat getting past this now, one underlying issue was that not all my chams were bound to the appropriate network spaces. Now most of them can reach their relations via the same subnet, so no routing issues.
[20:59] <KingJ> And at least going on the public subnet from outside seems to route correctly back?
[21:13] <thumper> morning