[00:42] beautiful.... http://reports.vapour.ws/releases/3520/job/run-unit-tests-xenial-amd64/attempt/353 [00:42] fatal error: concurrent map writes [00:58] that's awesome, that check caught something [00:59] i'm pretty sure that race is already tracked in a bug [01:07] thumper: before the break we were talking about moving gomassapi to github [01:07] in fact i think at the time I was going to address the races in that package [01:07] and that prompted the move to gb [01:07] and that prompted the move to gh [01:07] thumper i sent you an email about this on 1 dec last year [01:08] following up it looks like martin made the switch https://github.com/juju/gomaasapi [01:08] i'll send a PR [01:08] and get stuck into those races [01:09] oh, and it looks like gomaasapi is being used [01:09] that happened on the 5th ? [01:10] ok, time to fix that race [01:13] I did notice that martin did add it before christmas [01:14] davecheney: did you add the concurrent map write fatal? [01:14] Anyone see my Q from last night about getting list of all primaries on every instance of a subordinate? Is here the right place to ask, or would I be better taking it to #juju? [01:15] blahdeblah: what is the rationale for this? [01:16] I'm working on a subordinate to automatically publish unit public addresses in DNS with no additional code or user intervention. [01:19] (And automatically drop units out of DNS if they fail status checks when update-status hook is called, but that's not really important here...) [01:20] thumper: that was added to 1.6 [01:20] i'm surprised it made it into the versino in xenial [01:21] my guess is xenial is using some 1.6 beta [01:21] blahdeblah: sorry, can't help with that, but yes, either here or #juju [01:22] Any suggestions about whether I'm on the right track or not (i.e. there isn't a way to query all primaries directly from a single subordinate unit)? [01:36] thumper: https://github.com/juju/gomaasapi/pull/3 [01:36] this repo doesnt' appear to have gb or a bot [01:36] ? [01:37] gb ? i mean rb [01:37] actual change is here, https://github.com/juju/gomaasapi/pull/3/files#diff-cef8a1746ed33f0946c8dc5017058f15R599 [01:45] * thumper sees if it has a bot [01:46] thumper: interesting [01:46] there is a bot, but no reviewboard [01:46] can't say I mind [01:46] * thumper shrugs [01:51] thumper: https://github.com/juju/juju/pull/4146 [01:51] passes stress.bash on my machine [01:52] done [01:52] i'm sort of surprised that fix worked [01:53] but there is only one way in to the maas api [01:53] so sticking a lock right there did the job [01:53] which is good [01:53] 'cos doing it propoerly was going to be days of work [01:54] :) [02:01] Can I get a quick review? http://reviews.vapour.ws/r/3562/ [02:06] davecheney: did that PR fix one of the intermittent failures we're seeing on wily / xenial? [02:06] cherylj: i cannot say for sure [02:06] if the failure wasn't related to maas [02:06] then probably not [02:08] davecheney: okay. Please don't land anything else to master until we actually get a blessed revision and cut an alpha1 [02:08] unless it fixes one of the failing tests :) [02:14] cherylj: sorry, thumper approved it [02:15] cherylj: this fix was to fix the curse [02:15] on master [02:15] if it fails to merge I won't retry [02:20] thumper, davecheney yeah, if it's to address a current test failure, that's fine [02:20] thanks for doing that [02:20] it wasn't clear that's what it was doing [02:21] oh heh 1.6~beta2 is in xenial [02:21] who uploaded that? [02:22] ¯\_(ツ)_/¯ [02:22] oh xnox [02:23] fatal error: concurrent map writes? oh I see gomaasapi in the stack now. [02:25] which means i should update golang-race-detector-runtime too i guess [02:26] looks like the other master failures were joyent issues [02:27] joyent provider also has long standing races [02:29] davecheney: and we had to move to another (more crowded) region recently [03:01] huh... who woulda thunk it [03:02] marshalling (1<<64-1) as uint64 value becomes 0xffffffffffffffff, and unmarshalling works into uint64 [03:02] but other smaller values are 'int' [03:02] * thumper goes to write a schema hole to push this through === MerryChristmas is now known as benonsftware === benonsftware is now known as benonsoftware [03:57] anyone? http://reviews.vapour.ws/r/3568/ [04:00] davecheney: ^^ ? [04:03] thumper: responded [04:03] ta [04:03] you can tighten up the switch statement some [04:03] other than that, lgtm [04:03] davecheney: I don't see it [04:04] ah [04:04] GH [04:04] davecheney: yeah, nicer on one line [04:08] and you move the case that used to fall through the switch into the switch body [04:08] i like methods than have a switch statement to end with a switch [04:08] you know once you get into the switch, it can only hit one of the cases [04:09] * thumper tries to beat the bot [04:10] * thumper wonders if there is a bot on juju/schema [04:10] then you don't have to rememver, hmm, this switch case doesn't do anything ... oh, i have to keep reading the file [04:11] Lovely [04:11] did for both Uint and Time [04:12] * thumper manually merges [04:13] davecheney: before I manually merge, want to add a mark to GH? [04:45] * thumper departs === mwhudson is now known as Guest92985 === Guest92985 is now known as mwhudson [09:36] Bug #1460175 changed: apiserver_test authhttp_test SetUpTest.debugLogSuite failed [09:46] frobware: you got an LGTM by the way [09:52] voidspace, much obliged. [09:57] dooferlad, I will pick up the VLAN bugs/issues on 1.25. [09:57] frobware: thanks! I will get on with the demo page then. [09:58] dooferlad, could you pick of the '@' for '=' first. [09:58] frobware: sure. [09:58] dooferlad, we also need to help voidspace out with the merge of master into maas-spaces. [09:59] frobware: I gave him a +1. Guess we can discuss in the standup [09:59] dooferlad, yep [10:00] omw [10:01] frobware: dooferlad: standup [11:13] voidspace, you tried merging into master. http://reviews.vapour.ws/r/3560/ [11:42] Bug #1535678 opened: The MAAS bridge script only works for debian based interfaces(5) files. [11:51] Bug #1535678 changed: The MAAS bridge script only works for debian based interfaces(5) files. [11:54] Bug #1535678 opened: The MAAS bridge script only works for debian based interfaces(5) files. [12:18] frobware: hah [12:18] frobware: did I set up the branches the wrong way round [12:18] voidspace, I would say so [12:19] frobware: oops [12:19] voidspace, close... [12:19] frobware: will close and recreate PR [12:27] voidspace, dooferlad: http://reviews.vapour.ws/r/3570/ - thx [12:30] frobware: dooferlad: attempt two (onto the right branch!) http://reviews.vapour.ws/r/3571/ [12:34] voidspace: if it is the same as before, but with the right branch target, it already has a +1 from me. [12:34] dooferlad: it is [12:34] frobware: looking at yours [12:35] voidspace: +1 it is then [12:35] dooferlad: thanks, I've hit $$merge$$ on it [12:35] voidspace, frobware: https://github.com/juju/juju/pull/4147 [12:37] dooferlad, LGTM except for jam's comment. [12:37] (or observation) [12:38] frobware: add-juju-bridge.py:is_active, if an option is 'bond-master' then you return false [12:38] frobware: that's a separate, unrelated, change to the vlan bridging change - right? [12:39] voidspace, nope. [12:39] frobware: the big change is that in _bridge_vlan you no longer check active interfaces [12:39] frobware: ah, ok [12:39] frobware: what's bond-master? [12:39] voidspace, bond raw device now become special too [12:40] frobware: what's a bond raw device? [12:41] voidspace, it is to protect these stanzas of this form: http://pastebin.ubuntu.com/14574966/ [12:42] frobware: ok, what are they? [12:42] frobware: why do we not bridge them? [12:42] voidspace, look at this example - http://pastebin.ubuntu.com/14574970/ [12:42] voidspace, we have a bond but the bond has two vlans on (top of) it. [12:43] frobware: if it's manual wouldn't it be safe anyway? [12:43] voidspace, the correct bridging should be http://pastebin.ubuntu.com/14574972/ [12:44] voidspace, no because bond0 becomes bridged. bond0 => br-bond0, so in those cases we shouldn't create bridged for eth0/eth1 (which are the bond raw devices). [12:45] voidspace, if we did eth0/1 in that example. you would get br-bond0 and br-eth0 (and br-eth1). [12:47] frobware: ok, thanks [12:48] voidspace, did I confuse things? does it make sense? [12:48] voidspace, it's too long since I did the actual change. :) [12:48] frobware: I'm just looking at the original code to see how we now treat that differently [12:50] frobware: as far as I can see, eth0 and eth1 in that example are manual, so they would both have been treated as inactive before anyway - even without checking for bond-master [12:50] voidspace, agreed. [12:51] frobware: that bond-master change (specifically) doesn't make any difference for the examples you showed [12:51] they would only change behaviour for a bond-master that was dhcp / static [12:54] frobware: and that bond-master change isn't tested as far as I can see [12:54] frobware: other than that LGTM [12:55] voidspace, test is in the case that uses networkDHCPWithBondInitial [12:56] voidspace, ah, you mean if the bond0 config is static? [12:57] frobware: I mean a test case where is_active would have returned true before the change but returns false now [12:57] frobware: so yeah, a bond-master config that is either static or dhcp [12:58] voidspace, and we're talking for the raw eth0/eth1 device? [12:58] frobware: well, whatever sort of stanza that code is intended to be for [12:58] so yes I think [12:59] but a realistic example in the test would make the intent of the code clearer [12:59] voidspace, I'm now beginning to wonder if that's a case we can run into. a bond's raw devices should always be manual, therefore !active. [12:59] right [13:00] that was my half suspicion, if it's not a case we can ever hit then the code doesn't need to be there [13:00] with networking I don't mind it being there "just in case" though, but in which case there should be a test [13:01] maybe with a comment that it's not a likely case and this is defensive code [13:13] voidspace, you know what would be better here... if we moved the tests to python and then looked at the coverage. [13:21] frobware: heh, indeed === benji is now known as Guest37973 [14:09] Bug #1465307 changed: 1.24.0: Lots of "agent is lost, sorry!" messages [14:17] mgz, blimey - so retries was intentional! [14:18] jamespage: yeah, though I'm not sure how well publicised it was, didn't get any responses on the list [14:19] Bug #1465307 opened: 1.24.0: Lots of "agent is lost, sorry!" messages [14:19] mgz, well is was -dev rather than straight up juju [14:19] mgz, I responded in the bug and the ML - we should turn this off... [14:20] I thought I had responded at the time, but I guess I just poked bogdan about it on irc [14:22] Bug #1465307 changed: 1.24.0: Lots of "agent is lost, sorry!" messages [14:28] Bug #1465307 opened: 1.24.0: Lots of "agent is lost, sorry!" messages [14:31] Bug #1465307 changed: 1.24.0: Lots of "agent is lost, sorry!" messages [14:37] Bug #1465307 opened: 1.24.0: Lots of "agent is lost, sorry!" messages [15:21] jamespage: fwiw, from what I remember we had an attempt at making it opt-in, but then we decided it was a good idea to always do it [15:22] I was waiting for somebody to get hit by it for a while :p [15:23] I think the reasoning was that hooks are supposed to be idempotent anyway, so it wouldn't hurt to always do it [15:47] bogdanteleaga, hook idempotency is important and a good feature, but if somethings failed, it breaks out of that assumption I think [15:49] jamespage, I think the assumption is they're still idempotent even if they fail (as in they will fail in the same way based on some condition) [15:50] how does the opt-in thing sound? [15:51] bogdanteleaga: opt-in? [15:53] I was thinking about having a option in the charm to specify whether the author wants retries or not [15:53] bogdanteleaga: that is a problem [15:53] you see retrie is because of juju, not of the charm [15:53] bogdanteleaga: we could also put it behind a config option [15:55] perrito666: not sure I follow [15:55] cherylj, you're talking about environ config? [15:55] bogdanteleaga: yeah. like juju set-env auto-hook-retry=true [15:55] bogdanteleaga: lets say the hook is update-status hook, and juju state server is for some reason not available, lets say upgrading, we dont want to have a charm in failed status just because state server happened to be upgrading [15:57] cherylj, yup, but why not make the granularity at charm level? [15:57] perrito666, won't that happen regardless of retries? [15:58] bogdanteleaga: if the hook is idempotent, that would not be a problem :p [15:59] perrito666, aren't we working with the assumption that they are? [16:06] natefinch: happy tuesday :) [16:07] that looks extremely like the prelude to bad news :p [16:08] I hate making changes in status [16:09] katco: happy tuesday [16:10] natefinch: just wanted to check in and see if you needed anything for your card (or anything else) [16:11] katco: nope, think I'm good. Card seems pretty straight forward. [16:12] natefinch: ok, cool! also sent you a meeting invite for this afternoon. 15:15, and then we have the meeting at 15:30 [16:13] katco: cool, I'll go read up for that, so I'm ready. what's the format, are we all going to talk to him at the same time? [16:14] natefinch: we'll discuss @ 15:15 [16:14] katco: ok [16:29] frobware: dooferlad: mega-monster-master-merge landed [16:29] frobware: dooferlad: do we have openstack meeting now? [16:30] voidspace: will ping you if anyone turns up [16:32] dooferlad: ok [16:43] hmm... so far changes on master to provider/maas/environs.go *are* on the merged maas-spaces [16:43] that's encouraging [17:06] ok, so found the first "lost" changes [17:09] natefinch: also, ericsnow needed a review on this: http://reviews.vapour.ws/r/3551/diff/# [17:10] katco: thanks for bringing that to my attention, I hadn't gone to look at reviewboard this morning [17:29] downloading lxd images in a bar, the rest of the people using the wifi must be hating me [17:29] a lot [17:36] perrito666 chaos_wolf.png [17:41] perrito666 http://i.imgur.com/p2jAdlk.jpg [18:01] lazypower: actually I was drinking coffee and having lunch [18:01] but given what they charged me, I presume the bw was more than paid :p [18:01] perrito666 thats fair. I feel that way about panera [18:25] Bug #1535838 opened: Juju won't let me use some instance types on AWS [18:28] cherylj, w/1.25.3 deb: first bootstrap attempt failed (in a different way). the machine's e/n/i looks good, and it is still reachable. but `dpkg -l | grep juju` is empty. error was: [18:28] failed to bootstrap environment: bootstrap instance started but did not change to Deployed state: instance "/MAAS/api/1.0/nodes/node-d4692494-8228-11e4-8078-d4bed9a84493/" is started but not deployed [18:28] i've got another bootstrap underway to see if i get the same. logs, collected too. [18:28] Bug #1535838 changed: Juju won't let me use some instance types on AWS [18:29] from the maas perspective, machine is "deployed" without error === benji_ is now known as benji [18:37] Bug #1535838 opened: Juju won't let me use some instance types on AWS [18:37] beisner: did you use --upload-tools? [18:38] mgz, indeed. got a new run going now. [18:41] natefinch, question about windows workloads.. if I juju ssh to a windows workload, would I have access to powershell commands, or just cmd.exe ? [18:42] bogdanteleaga, was going to ask you as well ^^, though it's probably past your eod [18:43] I can do quick questions [18:43] you can't ssh to a windows machine now [18:43] we need winrm for that kind of functionality [18:43] and it's not implemented yet [18:44] best thing you can do is rdp into it, or winrm manually [18:46] see bug 1426729 bug 1426730 [18:46] Bug #1426729: juju-run does not work on windows hosts [18:46] Bug #1426730: juju debug-hooks does not work on windows [18:49] mgz, cherylj - 2nd and 3rd bootstraps a-ok. now deploying some misc stuff to another unit and containers. will holler back. [18:49] thanks, beisner! [18:52] yw, cherylj ! [18:56] bogdanteleaga, mgz ok, thanks! [18:56] ericsnow: what's the point of the extra level of indirection of the serialization struct in this review? http://reviews.vapour.ws/r/3551/diff/# [18:57] natefinch: consistent serialization in the various places where we need to [19:02] ericsnow: This feels like it's mixing concerns. The formatted stuff is getting mixed into the api<->non-api conversions... [19:04] katco, natefinch: quick review please: https://github.com/juju/utils/pull/188 [19:05] natefinch: how so? [19:05] katco: with that utils patch + my current branch, resource-get is working! :) [19:05] ericsnow: yes! [19:06] * katco does a happy dance [19:06] ericsnow: awesome [19:06] ericsnow: when i have more time, i'd love to hear what bugs you ran into [19:06] katco: just read through the commit history of the branch :) [19:06] ericsnow: good call [19:10] ericsnow: re: the serialized stuff: the logic to format a charmresource now lives outside the formatter, which is bad. It should have all of that self-contained so that it's obvious that a change to that code changes the outputted text. In addition, you've split the conversion into two steps, x -> String, string -> y, whereas before it was x -> y, making it clear that the conversion from x to y needs to be maintained (and making it easier to see [19:10] where the data is coming from). [19:12] ericsnow: it feels like going too far with DRY. The conversions happen to be similar, but they aren't required to be identical, and by merging it all into a single thing, you're tying things together too tightly. [19:13] natefinch: I don't see how anything is being tied to tightly to anything else [19:14] natefinch: across our implementation we have a consistent pattern of serialization [19:14] natefinch: I factored that out so that it is more maintainable [19:15] ericsnow: it was already maintainable, because they were confined to single functions that did exactly what we needed to maintain, convert X into Y. Now everything is in two functions, convert X into serialized, convert serialized into Y. [19:16] ericsnow: and we don't even use the fingerprint field from serialized for the formatter, which is a red flag [19:17] natefinch: how is that a red flag? [19:17] ericsnow: it shows that the formats are only coincidentally the same.... and for example, that field is not the same. [19:19] ericsnow: and the code for IsPlaceholder is only used in the formatter, but the logic exists way far away in the serialized code [19:20] ericsnow: I could maybe be convinced of it being useful for api->resource/charmresource, but I really think it's inappropriate to put formatter logic anywhere but in the formatter. [19:21] cherylj, mgz - ok, some basic throw-it-at-the-wall success: http://pastebin.ubuntu.com/14577040/ :-) one odd thing, eth3 (unused) is getting some unexpected definitions in e/n/i. [19:21] though that is not impacting this particular deploy [20:00] morning folks [20:00] thumper: morning [20:01] natefinch: moonstone [20:03] frobware, dooferlad, if you're still around, can you checkout beisner's comment above? [20:31] sinzui: there are a couple other patches that we want in alpha1 that weren't tested in this blessed run. Can we run master again? [20:32] sinzui: it pulls in the MAAS fixes that we talked about in the standup [20:32] cherylj: CI saw the commits and has already started a new test of master [20:37] Bug #1535891 opened: Feature request: Custom/user definable cloud-init user-data [21:17] perrito666: ping [21:17] menn0: pong [21:17] perrito666: I'm looking at your XDG compatible PR [21:17] perrito666: what do you mean by "location for juju config files is not .config/juju or XDG_CONFIG_HOME/juju" [21:18] menn0: lemme go check [21:19] menn0: there, corrected, apologies [21:19] perrito666: it seems like the change is making it so the default juju home is indeed ~/.config/juju [21:19] perrito666: thanks [21:19] menn0: it follows the xdg standard [21:19] Bug #1535891 changed: Feature request: Custom/user definable cloud-init user-data [21:20] perrito666: yep I get it. The "not" was confusing :) [21:20] it is either XDG_CONFIG_HOME/juju or ~/.config/juju depends if the first is defined, it usually isnt [21:20] the standard dictates that the later is the default value [21:20] extra context -> http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html [21:21] perrito666: thanks. I'm up to speed with that but it's good to have the link to the spec. [21:23] menn0: tx for reviewing that, it is a boring long change [21:23] cherylj, I answered in the bug. make sense? [21:25] frobware: thanks for that update. It is not clear to me whether or not you'd be comfortable releasing what we have. [21:25] frobware: should we wait for your additional testing? or are we good to go? [21:26] cherylj, I can try now, but I may curtail if it goes too long. [21:27] frobware: so then we should wait? :) [21:27] cherylj, I don't think we can get into the situation I envisage as we would always have at least one NIC up. If there are no NICs up (at all!) bootstrap is highly unlikely. :) [21:28] frobware: heh okay. Let me know your results when you EOD and we'll make the call to ship it or not [21:43] frobware, cherylj - ++comment @ "that bug" [21:44] beisner, I'm struggling to understand why (in my own head) the additional nameserver entries become a problem? [21:45] beisner, the indentation is confusing on the dns- entries added by maas/curtin. They belong to an interface. [21:45] frobware, they *might* not. it's just not consistent. (why just eth3? what happened to eth2 and eth1 if eth3 got that treatment?) and it's new behavior from 1.25.0, 1.25.1 and 1.25.2 [21:46] mpontillo, ping - I have some questions regarding the rendering of /e/n/i from MAAS/curtin... [21:46] so i'm just raising a flag that this could smell of some future trouble. [21:47] beisner, to me it appears that MAAS/curtin will always add a dns-nameserver entry to /e/n/i. The way that it does it makes it appear that they're top-level stanzas whereas they should be attached to the iface. [21:48] beisner, they _are_ attached to the iface. In your case 'auto eth3'. [21:48] http://pastebin.ubuntu.com/14577099/ [21:49] frobware, ^ exactly. there is no longer a global dns-nameservers setting. it's getting sucked into eth3's stanza. [21:49] beisner, I would agree that the association to eth3 is new, but then again that's because we were parsing it badly. [21:49] whereas without juju, there is a top-level definition of dns-nameservers. [21:50] beisner, I think the problem is that there's no notion of top-level dns-* stanzas. [21:50] beisner, if you read $(man interfaces) there's no mention of dns-* [21:51] beisner, if you read $(man resolvconf) there is the notion that an interface can have a dns-* option. [21:53] beisner, and, AFAICT, there are few mentions of nameservers in the ifupdown package. http://pastebin.ubuntu.com/14577985/ [21:56] Bug #1535916 opened: juju upgrade-charm should recognize the force flag [21:58] frobware, indeed. everything i see also says dns-nameserver belongs inside the iface stanza. so is it a bug that maas has been placing it at the top level all along? [21:59] beisner, I think the issue is that the indentation make it appear that dns-* options are top-level stanzas. [21:59] frobware, to be clear, top-level dns-nameserver does work in an e/n/i file, regardless of presence in the man pages. [21:59] perrito666: review done. I don't think it's quite there yet. [22:02] frobware, oh heck. dns-search dellstack gets dropped from top-level, AND it doesn't pull into eth0. instead it's in eth3, which isn't even up. i'm reasonably confident this is not desired. [22:02] beisner, does eth3 have an auto stanza? [22:03] beisner, if so, you can verify its UPness with: ip -d link [22:03] frobware, top is before juju, bottom is after juju. http://pastebin.ubuntu.com/14577099/ [22:03] frobware, eth2 and eth3 aren't even cabled up on these boxes. [22:04] beisner, can you cut+paste the output from that state using ip -d link [22:06] frobware, ip -d link: http://pastebin.ubuntu.com/14578067/ [22:08] i've got to depart, EOD, but can be back online in ~+4hrs. [22:08] beisner, cherylj: see discussion on #maas [22:09] frobware: I'm following :) [22:13] cherylj, given the differing opinions, do we want to hold fire here? It seems we need to nail this down once and for all. :( [22:14] beisner: is it okay if we take another day or so to figure this all out? are you guys working with something stable now? [22:14] I think I missed him [22:15] frobware: we can pick this back up tomorrow. [22:15] frobware: but please do add an update to the bug with a current plan before you head off to bed [22:18] menn0: tx a lot [22:19] menn0: I agree a lot with your review, tx [22:23] cherylj, what's interesting is that if `dns-*' is a top-level stanza this is pretty much how we were previously interpreting it. [22:26] frobware: so what's your thought now? to ask maas / curtin to create juju-br0? [22:27] cherylj, too much of a change right here, right now. but it's something to discuss for ongoing releases. [22:28] frobware: okay. For 1.25.3, do you need to change what you have now? [22:30] cherylj, no, don't believe so. but I just updated the bug. it's getting late for me to summarise what we have & do. === axw_ is now known as axw [23:26] Bug #1336473 changed: Support new t2 instance types on AWS [23:29] Bug #1336473 opened: Support new t2 instance types on AWS [23:32] Bug #1336473 changed: Support new t2 instance types on AWS [23:35] Bug #1336473 opened: Support new t2 instance types on AWS [23:40] perrito666: FYI, your messages are coming up in the hangouts thingy in gmail/inbox [23:40] axw: the writing in another chat was ajoke or I actually was on the wrong chat? [23:40] perrito666: as opposed to the hangout video window [23:40] perrito666: I guess because you're using your tablet or phone or whatever? [23:40] mm that sucks [23:40] axw: exactly, hangouts finds new ways of sucking [23:41] perrito666: u typed messages? [23:41] anastasiamac: I did [23:41] perrito666: i did not see any ;( [23:44] apparently there is no way to access the video chat from the mobile app [23:44] Bug #1336473 changed: Support new t2 instance types on AWS [23:50] axw: anastasiamac: will be afk for a bit, electrician on way to my house [23:50] wallyworld: \o/ [23:51] wallyworld: i've pm-ed u too [23:51] wallyworld: see you later, minus arm and leg [23:51] :D [23:53] frobware: sorry, I was out for an appt - back now. what's up?