[03:17] babbageclunk: hey there [03:17] babbageclunk: can I get you to look at a PR for me? [03:18] babbageclunk: https://github.com/juju/juju/pull/7821 [03:23] thumper: sure [03:23] babbageclunk: thanks [03:24] babbageclunk: I'm working on a followup to that one [03:24] that builds on it [03:35] axw: when you get time, would like a second opinion on the modelling for the firewall rules. i've tried to keep it all very simple at the core data model; layers on top can add complexity if needed https://github.com/juju/juju/pull/7823 [03:40] wallyworld: ok, will look in a bit. feeling like crap, been sneezing nonstop all morning... going to go lie down after [03:40] axw: that's no good, it can wait, go afk and rest [03:41] axw: seconded, go rest [03:44] thumper: approved - minor comment about a confusing variable name. [03:44] babbageclunk: cool, thanks [03:44] wallyworld: looking at yours now [03:45] yay, ty [04:00] wallyworld: approved. [04:00] awesome, ty [17:42] giving 2.3 edge a test run [17:42] is there some kind of endpoint config for my model [17:42] lets say the model from which machines are offering [17:42] or applications are offering [17:43] take the use case of an application deployed to maas [17:43] on private networks [17:43] relating to an application in a public cloud [17:44] I seem to remember this being discussed somewhere [17:44] possibly [17:44] ha [17:45] anyone know about a model config that defines a public egress gateway or something? === meetingology` is now known as meetingology [20:56] thumper: veebers: balloons: would you guys be free now for release call? [21:00] bdx: with the latest edge, you can do what you want. you offer the endpoint in the public cloud for example. if your maas is behind a NAT firewall and traffic originates from a given NAT address, you can either set a model config "egress-subnets" or when you relate to the offered endpoint in the public cloud, use "juju relate --via ". in each case, subnet is a CIDR, eg /32 [21:00] wallyworld: I could be in 5, balloons is off today. [21:01] ok, that would be great [21:02] wallyworld: thats great! thx [21:02] bdx: the model config is global for all relations, the --via option is per relation [21:03] bdx: i have tested with mysql in aws, and i then deploy mediawiki to a lxd cloud on my laptop; similar to your set up with maas i think [21:03] I see, perfect .... yeah I think thats what was stopping my postgresql relations earlier [21:03] Ill give it a whirl, thanks [21:03] bdx: ah psotgres - there will need to be some charm updates, it may not work out of the box just yet [21:04] gotcha [21:04] it might work, but the postgres charm needs to update the hba.conf [21:04] and there's internal juu changes in progress to allow things to be modelled properly [21:05] i don't think the NAT scenario would work just yet [21:05] for postgres anyway [21:05] it will all work real soon [21:11] ok [21:11] not sure if this is a corner case or not [21:12] so like in my datacenter, we have a direct route to our aws us-west-2 vpc [21:12] and vice versa [21:13] the routing tables in aws point back to my private networks in the datacenter [21:13] my datacenter (MAAS) nodes, and my aws instances dont have to traverse the WAN to talk [21:16] because they talk via a virtual private gateway, and have fiber straight to our racks at the datacenter [21:16] so for my controllers/models [21:17] I would want the services to talk over the VPG and not the wan [21:17] for my on-prem <-> aws instance [21:19] we also dont get charged for data that travels in and out of our racks at the datacenter to us-west-2 [21:20] I'm wondering if providing the '--via' for my internal nets will make juju do what I want it to do [21:21] (route via the VPG instead of externally) [21:22] because I've already got the routes [21:22] I guess this will turn into a matter of juju wanting to support the remote relation via the public endpoint eh? [21:22] hmmmm [21:35] wallyworld, veebers: oh, have you had the release call? [21:35] here I am sitting all alone [21:40] thumper: heh yeah we met as wallyworld needed to pop out. You want to meet? [21:40] veebers: is there anything interesting to discuss? [21:40] thumper: not really, just we have 2 things being worked on, they should hopefully be done this week for release, otherwise we push out a little longer [21:41] veebers: I do have a question for you though [21:41] veebers: http://ci.jujucharms.com/job/github-merge-juju/216/ [21:41] veebers: how do I find out what failed from this link? [21:41] let em look now [21:42] hmm... [xenial] Error: retrieving gpg key timed out. [21:42] thumper: hit th e"open blue ocean" link on the side there, gives nice logging outpt [21:43] thumper: but yeah, looks like a hiccup there failed it :-\ [21:43] what's blue ocean? [21:43] looks pretty though [21:45] thumper: blue ocean is a UI layer for jenkins designed for the pipeline builds (a way of declaring builds in code etc.) [21:46] thumper: we use it for our merge and check-merge jobs, we where going to use it for the ci-run replacement, but have pivoted away from that [21:47] * thumper nods [23:24] thumper: ok - after that hump of cloud names the amazon migration fails because we use different machine tagging: juju-env-uuid vs juju-model-uuid. [23:24] thumper: this doesn't happen on maas [23:25] thumper: since we use the agent-name value from maas. [23:25] ok [23:25] thumper: do you know how we do it in openstack? [23:25] I'll have a dig. [23:28] thumper: hmm, looks like it'll be a problem there too. [23:28] hazaah [23:30] thumper: is canonistack on openstack? [23:30] yep [23:31] ok - working on sorting that out now