=== axw-away is now known as axw [03:00] wallyworld: https://codereview.appspot.com/91740043/ [03:00] tested live with maas [03:00] axw: already looking :-) [03:00] cheers [03:00] going to go do some packing, bbiab [03:09] wallyworld: hrm, it is selecting the instance but it doesn't seem to be bootstrapping. I will continue investigating... there may be another change required to bootstrap though [03:09] ok [03:09] branch looks ok - i did have a suggestion about the error checking in bootstrap [03:10] i've +1ed it so you can land once it works :-) [03:21] wallyworld: testing again with a fresh maas node, could've been because it was dirty [03:21] wallyworld: I didn't want to return other errors because we don't care about whether they're well formed [03:21] wallyworld: just that they're unscoped or not [03:22] bootstrap doesn't care if you specify an lxc placement with an invalid machine id [03:22] because it just doesn't support lxc placement [03:29] axw: ok, it makes sense now that i think a bit harder [03:31] alrighty, worked fine with a new node [04:09] wallyworld: https://code.launchpad.net/~wallyworld/juju-core/bootstrap-supported-series/+merge/216974 LGTM [04:09] morning all [04:09] jam: great thanks [04:10] wallyworld: fwiw I think we actually want to target 1.18 with that patch [04:10] jam: we want to get a lot of stuff into 1.18 [04:10] wallyworld: since 1.18 local is broken in the same way [04:11] i'll land in 1.19 first cause that ships tomorrow and then will back port [04:11] wallyworld: *I* find it much easier to land to 1.18 and then merge up, but as you wish [04:11] i just cherry pick :-) [04:12] but i can see that could get messy easier than landing to 1.18 first [04:12] wallyworld: 1 case isn't bad, N cases starts to get hairy [04:12] wallyworld: can I ask to have you peek at https://code.launchpad.net/~natefinch/juju-core/045-amd64plz/+merge/216612 [04:13] It looks like FindInstanceSpec doesn't like that we prefer amd64 now [04:13] and I think you have some familiarity with that code [04:13] sure [04:13] that was actually on my list [04:13] cause i tried to land it this morning [04:13] there's a couple of failures [04:14] jam: btw, is the weekly meeting on tonight with everyone away? i can't make it cause it's my son's birthday [04:14] wallyworld: you lazy slacker, how dare you have a family life! :) [04:14] yeah, bad i am [04:14] wallyworld: I think we'll still do it with whoever is around [04:14] but don't feel bad [04:14] sure, axw was wondering also [04:15] probs will just be discussing getting 1.19 out anuway [04:21] woot, maas-name is merged [04:32] axw: so that is "juju deploy --to maas-name:foobar" ? [04:47] jam: sorry was eating lunch. not quite; for one thing deploy/add-unit are not supported yet (I opened a new bug for that) [04:48] jam: we can now do "juju add-machine [env-name:]" [04:48] jam: also s/add-machine/bootstrap/ [04:48] axw: [env-name:] why wouldn't it be -e envname ? [04:49] jam: it's how fwereade wanted it, not exactly sure when we'd have env-name != implied env [04:49] jam: but you can leave it out altogether and it uses the implied env name [04:49] wallyworld: lp:~wallyworld/juju-core/bootstrap-supported-series just bounced with test suite failures [04:49] jam: I *think* it's for multi-env [04:49] ah, ok, just about to propose the i386 branch [04:50] will look in a bit [04:50] wallyworld: I'm looking at your constraints vocabs patch [04:50] great ta [04:58] wallyworld: reviewed https://codereview.appspot.com/96730043/ [04:58] ta, will look rsn [04:59] wallyworld: On your SeriesToUpload patch, I was surprised to see Lucid [04:59] jam: i didn't add it, it was already there [04:59] k [05:00] i think the test just set it up as the preferred series in config [05:00] just to have something other than precise to use [05:02] jam: i tweaked some metadata and a test and fixed a nil pointer issue and it seems to work now https://codereview.appspot.com/90720043/ [05:03] wallyworld: LGTM [05:03] ta === vladk|offline is now known as vladk === vladk is now known as vladk|offline === vladk|offline is now known as vladk === vladk is now known as vladk|offline [06:56] axw, jam: it's not really env-name, it's provider-name (or, heh, really more like account-name) but since we don't have those concepts in play at the moment we can't sanely reference them [06:56] fwereade: fwiw, Id rather bring that in when we actually have multi-provider environments [06:57] but as long as you can just leave it off, I guess it is fine. [06:57] I do wonder if we want to continue the --to syntax [06:57] yeah, just as long as we don't prevent future use [06:57] since that would match how it would end up on things that aren't bootstrap and add-machine [06:57] but I suppose add-machine already uses the ssh: syntax [06:58] jam, axw: yes, Iwould generally prefer that we not make a big deal of the prefixes; I just wantthem in place for when we do [06:58] jam, axw: I think a placement directive is meaningful both as a positional arg and as a --to payload [06:59] jam, axw: and it's to our benefit to make it look nice and easy in both cases, just as it is to our benefit to design it such that we can expandin plausibledirections in future without having to change everything ;) [06:59] me too. "I'm bootstrapping $machine" vs. "I'm deploying $service to $machine" [07:01] fwereade: axw: any chance that your change allows "juju bootstrap ssh:user@host" at the same time ? [07:01] axw: although, hmm, I suddenly fret that --to works better on bootstrap... [07:01] jam: no, I did think of that, but it's not possible atm [07:01] jam: because we use the bootstrap-host when preparing [07:01] axw, jam: I'm not quite sure what positional arg I would be saving it for [07:01] axw, ah, that's a shame [07:02] jam, fwereade I added a TODO in provider/manual to revisit it tho [07:02] axw: AIUI we have a bug open on it [07:02] axw, it does STM that we don't really even need an environments.yaml for that case,though [07:02] ok [07:02] axw, that's a bigger change, but one we should make soonish [07:03] axw: bug #1282217 [07:03] <_mup_> Bug #1282217: Specifying bootstrap-host requires editing environments.yaml

[07:03] axw, I haveto write it upproperly for vegas [07:03] and possibly bug #1282642 [07:03] <_mup_> Bug #1282642: Bootstrap prefers .jenv over environments.yaml

[07:03] ah yes, that's right [07:03] fwereade: so AIUI in bug #1282217, we need it in Prepare because we potentially call SyncTools before we bootstrap [07:03] <_mup_> Bug #1282217: Specifying bootstrap-host requires editing environments.yaml

[07:03] jam, fwereade: the main issue is that we have multiple ways of preparing an environment, and it currently needs to be usable before bootstrap [07:03] yep [07:04] however, sync-tools is sort of dying anyway, so I'd rather not tie us to that [07:04] jam, yeah, but I'm not sure there's any reasonable remaining justification for sync-tools [07:04] jam, axw: I don't *think* there's anything beyond sync-tools keeping Prepare distinct from Bootstrap, is there? [07:05] fwereade: only plugins, but they probably don't need it [07:05] fwereade: Prepare is the time when we take the rough template and fill out all the random bits [07:05] so I don't mind it as a step [07:05] but that step can happen only during bootstrap for all I care [07:05] that would be nice [07:05] jam, yeah, I'm not really against *prepare* so much as I am against environments.yaml [07:05] fwereade: I *think* the fact that we gave bootstrap --source means we've replaced the other needs we had [07:06] cool [07:07] fwereade: with some possible caveats [07:07] like I think we are missing a way to say "Give me a copy of the tools that are at $URL" [07:07] the juju-metadata plugin uses PrepareFromName. does it need it to? [07:07] and --metadata-source requires it to be a local path [07:07] so you can bootstrap from a public URL either [07:07] I think it might, so we can prepare tools and metadata in keystone or whatever [07:07] axw: I'm a firm believer that metadata should not be a plugin [07:08] axw: and I think it is in the same boat as sync-tools, in that when you are preparing your own image/tool metadata [07:08] you can't have an env bootstrapped yet [07:08] because you're creating its infrastructure [07:08] right... so it just needs to be able to deal with an "unprepared" env config [07:09] axw: but I don't think manual actually needs it, since you're not doing image lookup if your target is manual [07:09] jam, axw: I dunno, I feel like creating metadata and uploading it are very distinct things [07:09] you may need it for tools [07:09] jam, axw: and that separation points towards the pluginness being a good thing [07:09] tohugh again, I think --source for bootstrap is a better workflow there [07:09] jam, axw: it probably shouldn't be about environments at all [07:10] jam, axw: plugins for metadata generation, for them as needs it [07:10] fwereade: actually, I firmly believe it shouldn't involve an env, because I often try to configure stuff, and I don't have a default env, and it just goes "poo" you must set -e [07:10] fwereade: afaict it doesn't really do anything with the env, at least for generate [07:10] maybe validate will use it for where to find the stream data [07:10] jam, axw: --source args that let you point at local or remote metadata that gets pushed into your environment [07:11] jam, axw: would be nicest of all, really, to have validate again just point at a metadata source [07:11] jam, axw: then if an environment uses that source, yay, you know it's validated [07:12] fwereade: how do point at the environment storage? [07:15] although hm, the tools don't actually upload to env storage? [07:15] axw: the metadata does [07:15] or can [07:16] jam: sorry I meant the plugin. doesn't look like it does... maybe there's a flag I'm missing [07:17] anyway, if we can make it so prepare is only ever called by bootstrap that would be awesome [07:19] axw, jam: yeah, I don't think we really need to -- although I think I'm backing off the idea that you *can't* validate metadata for an env, it still seems perfectly reasonable to just take the source from the env and check that source [07:21] seems sane. I think once it's in the env, it should be reasonable to assume it's valid [07:48] fwereade: I feel like you have a better handle on what should be happening while hooks are firing, I think I've gotten the context down small enough in https://bugs.launchpad.net/juju-core/+bug/1311825 but I don't quite understand why it does/doesn't do stuff [07:48] <_mup_> Bug #1311825: test failure UniterSuite.TestUniterUpgradeConflicts

[07:49] fwereade: do you want to Hangout about it? [07:50] jam, sure, but you may just be watching me catching up [07:51] fwereade: https://plus.google.com/hangouts/_/canonical.com/john-william [08:42] morning all [09:03] mfoord, heyhey [09:06] fwereade: o/ [09:10] jam, https://codereview.appspot.com/92720044 [09:11] fwereade: LGTM [09:11] fwereade: me thinks we might want that patch in 1.18 ? [09:11] since it is about making CI happier to make releases [09:34] fwereade: provisioner treats no tools as error: https://codereview.appspot.com/93720044 [09:37] morning all [09:43] morning natefinch [09:43] natefinch: care to start your day with a review ? https://code.launchpad.net/~jameinel/juju-core/1.18-provisioner-no-tools-is-fatal-1311676/+merge/217011 [09:45] jam: sure [09:52] morning [09:52] perrito666: morning [09:54] * perrito666 notices his bug resembles a mamushka doll [09:59] jam: not going to be able to make the meeting, I have to look after my daughter [10:00] axw: np [10:00] also I have tomorrow off - national holiday. see you all in vegas [10:00] axw: see you next week [10:01] fwereade: standup ? [10:02] axw: you can bring your daughter to the meeting its becoming a thing :) [10:02] axw: see you in vegas [10:02] perrito666: you have a point :) [10:03] vladk|offline: group standup ? [10:32] * perrito666 sees the test running for too long and knows he is about to get an error === vladk|offline is now known as vladk [10:45] natefinch: you need to bring your daughter to Vegas. Daily standups without her just won't be the same... [10:45] mfoord: haha [11:25] jam: hey, could you help taking a look at http://paste.ubuntu.com/7315688/ for juju bootstrap with trunk version, 1.19.1-trusty-amd64 pls? [11:27] psivaa: known bug we won't fix, you have to use --upload-tools to bootstrap trukn [11:28] jam: ack, i think i tried that too. let me do that again. thanks [11:28] psivaa: bug #1308337 [11:28] <_mup_> Bug #1308337: 1.19.1 cannot bootstrap 1.19.0 (no longer installs mongodb-server during bootstrap)

[11:30] jam: thanks. with --upload-tools i got http://paste.ubuntu.com/7314791/ in a private cloud. not sure if the cloud being overly restrictive is any reason. [11:30] i'll try that with hpcloud [11:30] psivaa: you're using juju-core with gccgo and not compiling with static linking [11:30] psivaa: var/lib/juju/tools/1.19.1.1-precise-amd64/jujud: error while loading shared libraries: libgo.so.5: cannot open shared object file: No such file or directory [11:30] psivaa: you need to set flags, let me go look them up [11:31] psivaa: var/lib/juju/tools/1.19.1.1-precise-amd64/jujud: error while loading shared libraries: libgo.so.5: cannot open shared object file: No such file or directory [11:31] sorry [11:31] psivaa: INSTALL_FLAGS := -gccgoflags=-static-libgo [11:31] psivaa: so you should be doing "go install -gccgoflags=-static-libgo" when building juju from trunk [11:31] ack, will try that. thanks jam [12:02] anyone else having issues with publickey denied with juju ssh to machine 0? using local provider? [12:12] wwitzel3: your local machine isn't accepting your own ssh key, but that isn't that uncommon. ssh 0 is never guaranteed to work ,because most people don't even run openssh on their laptop/etc [12:12] wwitzel3: what command are you running? [12:13] eg "juju debug-log" never worked with local until recent 1.19.1-ish stuff [12:13] thumper turned debug-log into an api call. [12:43] jam: just juju ssh 0 [12:44] wwitzel3: right, that depends entirely on if "ssh localhost" works [12:44] wwitzel3: not something guaranteed for local provider [12:45] jam: well, I can run ssh localhost and it works as expected [12:45] wwitzel3: sorry, can you "ssh ubuntu@localhost" ? [12:45] jam: oh right, because that is the user it is expecting [12:46] canonical wiki not responding [12:46] and I want some lxc information from it [12:46] so that seems like a good time to go on lunch [12:47] back soon(ish) [12:47] miss you already [12:47] wwitzel3: liar :-) [12:48] mfoord: also irc server is not letting me connect [12:48] mfoord: wiki just came up for me [12:48] slow, but it did come up [13:10] fuuuuuu!!! [13:10] I can't land anything on the 1.18 branch on the bot, the test suite is broken on tip [13:10] didn't wallyworld have a patch recently because we had some test isolation issues when releases were made? [13:11] * wallyworld has vague recollections but can't recall the details [13:12] wallyworld: does https://code.launchpad.net/~jameinel/juju-core/1.18-provisioner-no-tools-is-fatal-1311676/+merge/217011/comments/515862/+download ring any bells ? [13:13] wallyworld: I'm just getting lots of "no tools available" failures on the 1.18 branch [13:13] even without my patch (if I SSH in manually and try it) [13:13] but it passes on my machine on trusty [13:13] jam: it's the changed lts thing [13:13] ah, ffs, LatestLTSSerise became trusty [13:13] yep [13:13] so all the tests that were expecting "precise" to just work [13:13] ... [13:14] jam: i fixed it in trunk with the SeriesToUpload fix [13:15] it sorta worked before but then we got the %LTS% placeholder put in [13:15] wallyworld: I can land my patch today by just editing /usr/share/distro-info/ubuntu.csv ... [13:15] and making Trusty come out next month [13:15] yeah [13:16] i need to backport a bunch of fixes to 1.18 [13:16] wallyworld: well, the test which failed now passes on the bot [13:16] \o/ [13:16] I feel a bit dirty, but I feel *very* pragmatic [13:17] sometimes that's fine :-) [13:18] jam: so it seems we won't have 1.19.1 for ODC unless we shift out some bugs [13:18] wallyworld: High bugs don't block releasing 1.19.1 [13:19] great [13:19] wallyworld: they're just the stuff I want next on everyone's queues [13:19] they probably block 1.20 [13:19] yeah [13:19] High 1.19.1 bugs do, High 1.20 bugs probably don't... [13:19] as we're essentially doing priority by keeping multiple milestones [13:28] natefinch: wwitzel3: can I get a trivial review: https://code.launchpad.net/~jameinel/juju-core/1.18-panic-parsing-jenv-1312136/+merge/217036 [13:28] we were ignoring an 'err' return that could cause a later pani() [13:28] panic() [13:28] + 1 we shouldn't do that [13:28] haha, taking a look [13:30] LGTM [13:31] dude! you guys are kicking a** on bugs! [13:33] alexisb: well, I feel like I'm reporting as many as I'm fixing, but we are doing a lot of them [13:33] jam :) understood [13:33] but finding them is important to [13:33] jam: that's interesting, because it was declared as a var and then used in scope at the bottom of the fuction, it wasn't an compile time error when we didn't use the err we get back from the function. [13:33] either way the progress is impressive [13:33] wwitzel3: hypothetically I should be adding a test for that path [13:34] jam are we seeing a lot of regressions from HA and vlan landing? [13:35] alexisb: we are seeing a lot of things that don't work when HA is enabled [13:35] not quite the same thing [13:35] when you don't *use* HA, then everything still works [13:35] :) [13:35] jam ack [13:35] that is better then HA breaking everything :) [13:38] natefinch, please remind me how arch selection works after your change -- do we pick amd64 by default, regardless of client? [13:38] alexisb: right. I think it falls under "not a regression, but fairly important bugs" which is reasonable [13:38] given that HA isn't by-default [13:39] natefinch, if so, am I right in thinking it should also resolve https://bugs.launchpad.net/juju-core/+bug/1274755 and https://bugs.launchpad.net/juju-core/+bug/1262967 ? [13:40] jam we will need to flush out the HA bugs and get them fixed before 1.20 [13:42] fwereade: I changed it to just select the same arch as the host if possible [13:42] fwereade: since jam had made a good point that otherwise we'll break --uploađ-tools [13:43] jam, for the HA sprint discussion... [13:43] fwereade: I don't think it fixes https://bugs.launchpad.net/juju-core/+bug/1274755 [13:43] that is that our canned data doesn't include other ARCH [13:43] do you think it is a mini topic or needs a full timeslot? [13:43] natefinch, that seems backwards -- aren't we restricting by available images/tools before going further? [13:43] alexisb: I think we're going to be talking a lot about next steps for HA, TBH [13:43] fwereade: https://bugs.launchpad.net/juju-core/+bug/1274755 is a test-suite bug [13:44] fwereade: so if you just run "juju bootstrap" it will pick something [13:44] if you later run "juju upgrade-juju --upload-tools" [13:44] We've at least had support requests [13:44] where they expected the latter to work, but were on say i386 [13:44] and you can't upload i386 tools to an amd64 env [13:45] I'm not *sure* what clouds would have amd64 and ppc64 and then run from a ppc64 client [13:45] fwereade: the arch check is the last thing we do, after other considerations (tools and constraints) [13:45] alexisb: I'm *mostly* concerned that we have time allocated to doing the work [13:45] ack [13:45] alexisb: We can do the actual discussion in the bar, but I do think it is going to have a longer tail if we really want polish [13:46] yep we are planning to but time aside for core coding [13:47] alexisb: so are you saying I can have time for my team to code, or time to discuss HA ? [13:48] I am saying we have already planed to have time for coding, and I can schedule time for HA discussion if needed [13:53] alexisb: sounds good [13:53] I realize I'm adding them late, but when I come across them, I figure it is better to bring it up [13:53] we'll probably be adding some during the week as well, I would imagine [13:54] yes something tells me this will be a dynamic plan [13:54] I am just trying to ensure we capture everything and make note of it [13:57] alexisb: certainly, and I *definitely* appreciate that I can fire off a "we should talk about this" and not have to actually schedule it myself [13:59] wwitzel3: I think the code in question wanted to do shared error handling, and then just didn't, or was refactored out of being shared. I can poke at it a bit more [13:59] wwitzel3: I can't land it yet on the bot because of the Trusty / Utopic stuff (still needs to land my other branch which fixes 1.18 branch to pass the test suite again) [13:59] Hi, I'm getting connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused' on bootstrap of local provider on trusty [14:00] natefinch, jam: dammt, I thought we'd done the SupportedArchitectures work to head that sort of problem off at the pass [14:00] wwitzel3: cfg is needed because it gets used later on [14:01] natefinch, jam: anyway, thanks, I won't close the bugs then :) [14:01] wwitzel3: and you can't return 'cfg' without returning 'err' I believe, we could declare 'err' more locally but we can't use := syntax [14:01] fwereade: *shrug* I'm not sure. I'm just giving my synopsis of the bug [14:01] since we don't have that platform on-hand to test it [14:01] maybe it works [14:01] wallyworld was doing testing on ppc64, right? [14:02] jam, indeed, but the evidence does not strongly point that way :) [14:02] /var/log/upstart/juju-db*.log has: "/bin/sh: 1: exec: /usr/lib/juju/bin/mongod: not found" [14:03] coreycb: do you have "juju-local" installed ? it should bring in "juju-mongodb" [14:04] jam: nope [14:04] coreycb: I believe in trunk we detect if juju-local is available and if not, request that you install it [14:04] jam, you remember updating the ec2instance types a couple of months ago? do you recall where you got the cpu-power scores? [14:05] jam, that fixed it. I don't think it notified me to but I could hvae missed something. I know it told me to install mongodb-server. [14:05] coreycb: 1.18 detected fixed dependencies, which were valid on precise, but not trusty [14:05] so instead we now require juju-local [14:05] which brings in the right things on both platforms [14:06] jam, ok I'm on 1.18.1-0ubuntu1 [14:07] fwereade: I believe they changed their webpages :( [14:07] jam, wwitzel3: we should declare err inside the if scope. Yes, you'll need to do it in two places, but it'll ensure the compiler knows if you don't use it [14:08] jam, yeah, and now the only provider that understood cpu-power no longer gives us values [14:08] fwereade: found it: https://aws.amazon.com/ec2/pricing/ [14:08] fwereade: it is under pricing, but not under instance types [14:08] jam, ah-ha! thanks [14:08] natefinch: i did [14:08] though it feels pretty wasted victory [14:09] natefinch: that is going to be something RSN someone is going to say "Why is this code duplicated" and pull it out as they refactor the function and forget to handle the err :) [14:09] but I *did* add a test for this case [14:09] jam, and there's some new ones, might as well add them (since I'm fixing a typo and looking them up anyway ;p) [14:09] note that the code still has another bug [14:09] which is if envs.Config() doesn't return IsNotFound [14:09] but returns some other err [14:09] it is going to break again [14:09] jam: yeah, I was going to mention that [14:11] natefinch: so you can pick up my patch if you want, but I'm way past EOD and shaving yaks is not a good start to my weekend [14:12] jam: no problem [14:12] natefinch: its pretty obvious that the author thought err was going to bubble up and be handled [14:12] but isn't [14:12] like, why handle only IsNotFound here [14:12] yep [14:13] natefinch: so I'd appreciate handoff of https://code.launchpad.net/~jameinel/juju-core/1.18-panic-parsing-jenv-1312136/+merge/217036. If you like it well enough, Approve it, if you want to tweak it, feel free [14:15] jam: sure, I'd like to handle the non-not found error [14:15] jam: seems like we don't need to handle notfound special there, just return whatever error we get [14:17] natefinch: sgtm, I'm not sure what errors we could handle [14:17] which means we probably want to move the Warningf that I have [14:17] up [14:17] and share the err [14:18] natefinch: the Warningf is because otherwise we don't inform the user that there data is bad, because we are trying to connect on the other Try [14:20] jam: so always warn if we return a non-nil error? [14:20] natefinch: I think we could not warn on NotFound [14:21] jam: yeah, that seems valid [14:21] jam: someone higher up is probably checking for isnotfound anyway [14:25] happy birthday to Vladk [14:25] jam: thanks [14:26] vladk: hey hb [14:26] why is calendar not telling me that its your bd? [14:27] vladk: nice job, do it again next year ;) [14:31] jam, another question about the m3 instance types -- they seem to accept both paravirtual and hvm images. do you know any particular reason to choose one over the other? [14:35] are individual juju command options documented somewhere? === vladk is now known as vladk|offline [14:36] coreycb: juju help [14:36] natefinch, duh, thanks :) [14:36] coreycb: np :) [14:38] alexisb, I've just realised I've been listening to the hold music on the cross-team call for 10 mins -- do you know if it's happening? [14:39] hmm 'juju debug' gets - ERROR control-bucket: expected string, got nothing [14:39] fwereade, I think mark sent a cancellation notice [14:39] sorry, juju debug-log [14:39] but you are not the first to ask so maybe not [14:40] fwereade: it just got all electro-funk on me [14:40] bloodearnest, yeah, it was a bit more soothing when I started listening [14:41] alexisb, well, I'll drop off for now, I'm around if I'mwanted [14:42] fwereade: same here. I just gave up. [14:42] fwereade: looking through my mail for any missed notice [14:42] rick_h_, couldn't find one, but iirc he is at gophercon [14:42] yep, conference has swallowed our teams [14:43] :) [14:43] yep sorry guys [14:43] I would run it but I dont have the leader code [14:43] and I am on a plane [14:43] all good, see everyone in 4 days [14:45] alexisb: I thought you were going to be there yesterday? [14:46] natefinch, I was [14:46] I ended up in the ER [14:46] it is a long story [14:46] alexisb: whoa, hope everything's ok [14:46] but I am headed that way now [14:47] yes just complications from the cold I had 3 weeks ago [14:47] but I promise everyone I am not contagious I wont get you sick [14:48] alexisb: heh... I thought I was getting over my three (now almost four) week cold a couple days ago, and it just got worse. [14:49]