[00:31] * babbageclunk goes for a walk [02:06] jam: FYI, https://azure.microsoft.com/en-au/updates/ga-multiple-ips-per-nic/ & https://azure.microsoft.com/en-au/updates/dual-nic-support/ [02:18] axw: oooooh [02:19] rick_h: :) [02:19] rick_h: also, did you see there's SR-IOV support, so you can have moar faster mellanox networks [02:19] rick_h: still in preview tho [02:20] axw: no, I didn't. I get the summary emails from GCE and AWS but not from Azure. I need to find that I guess. [02:21] rick_h: I'm not subscribed, I just stumbled across it. not sure where to subscribe to these sorts of things [02:25] axw: https://cloud.google.com/newsletter/ and https://aws.amazon.com/new/ (via rss) are the things I follow I think [02:25] rick_h: thanks. i'm on the google one already, prob should read aws too [02:26] * rick_h tries https://azure.microsoft.com/en-us/community/newsletter/subscribe/ to see if that'll send news [02:51] wallyworld, axw - I'm assuming we don't rely on the name of the firewalls created by GCE to be the hash of the rules, it's just how we make them unique. Does that sound right? [02:51] babbageclunk: that's my understanding, but to change the algorithm would require upgrade steps [02:51] maybe [02:51] or at least compatibility code [02:52] babbageclunk: no idea sorry [02:52] that's what I would expect though [02:55] wallyworld: I'm not changing the way the name's generated, just not updating it when we change the rules it contains (since it looks like that's not supported). The code finds firewalls by rules, not by relying on the name, so I don't *think* we'll need any upgrade steps. [02:55] that sounds ok [03:37] wallyworld: easiest review ever: https://github.com/juju/juju/pull/7246 [03:38] ok [03:38] I mean, I guess I have seen 1-line PRs, so it could technically be easier [03:43] babbageclunk: sorry, was just otp. don't we need to rename the rule with the new hash so it can be found next time? [03:44] or so that the name matches the hash [03:46] wallyworld: I don't think so - we don't find it by name, otherwise we wouldn't have been able to find existingFirewallName. You can see above in OpenPorts that it finds it by CIDR and/or port. [03:48] babbageclunk: ok, something is bothering me about having the name start out as a hash of the ports and then not being the hash. what happens if a new sec group is created with the old rules, there will be a name clash? [03:49] wallyworld: hmm, I see what you mean. [03:52] wallyworld: so in that case maybe we need to delete the firewall and add a new one? Although I guess that could kill connections. :( [03:52] babbageclunk: could do. can we rename a firewall? [03:53] wallyworld: oh right - maybe as a separate call from updating its rules. [03:53] wallyworld: reading some docs [03:53] ok [04:20] wallyworld: I can't find any way to rename one. [04:20] babbageclunk: create new one and then delete old? [04:21] babbageclunk: or maybe just use a uuid type thing to generate a unique name up front and not tie to rules hash [04:21] wallyworld: yeah, I was just about to say that [05:24] wallyworld: ugh, using a random number requires stitching errors through and making the tests handle nondeterministic results. Do you think I should do the add and then delete thing instead? Feels a bit more fragile though [05:25] babbageclunk: you can mock out the name generation for the tests using a func that doesn't error [05:25] and that returns a deterministic result [05:35] wallyworld: yeah, but there are are higher-level tests that also (incidentally) check the name because they're looking at calls. [05:36] wallyworld: oh, you mean reassign the function in export_test? [05:36] something like that, or pass in as a dep, so the test can control the name generated [05:39] wallyworld: yeah, I was passing it in as a dep (since I've seen people object to the rebinding), but it means that I need to pass it down multiple levels [05:40] wallyworld: tempted to make the tests not look at the random bit of the name. [06:30] babbageclunk: sgtm [06:31] jam: teeny review please? https://github.com/juju/gomaasapi/pull/69 [06:32] axw: I assume that information was always in the API response, even for older versions of MAAS? [06:32] jam: yeah, and we use it when connecting to MAAS 1.x [06:37] sgtm [07:14] axw: no rush, if you get a chance at some point https://github.com/juju/juju/pull/7239 [07:15] wallyworld: sure. pool leak dude is here, bbs [07:15] ouch, hope it's not too bad === frankban|afk is now known as frankban [08:44] wallyworld: pool has been losing water for months, just recently got to 3-4cm each day. my regular pool guy was hopeless, had a few shots at finding the leak [08:44] wallyworld: so called up a specialist and he found it in 30 minutes... [08:44] wallyworld: haven't seen the invoice yet, hopefully that's not too special [08:48] $1 for hitting it with a hammer, $999 for knowing where to hit [08:54] wpk: yeah, pretty much. except the guy who didn't solve the problem still charged $1000 (figuratively, not really that much) [11:26] axw: was it in a connecting pipe? or the pool itself? [11:29] wallyworld: wow \o/ m just curious if it's fixed :D regardless of where it is.. altho the location would probably determine the price of work.. [11:39] wallyworld anastasiamac: bottom of the pool. he swam down and filled the crack with some type of glue/filler [11:41] axw: niiice :) how old is the pool? some builders have extended warantees... [11:41] anastasiamac: good question/idea. I don't know - I'll check later === frankban is now known as frankban|afk [20:47] * babbageclunk is popping out, back in a bit