[09:15] <jam> so mgz, what pieces can I pick up so we can finish up the kernel params stuff, since we got Jenkins running again
[09:17] <mgz> so, what I still don't know how we're going to do is get the kernel options to the provisioningserver
[09:18] <mgz> also, did you see the notes from scott in last nights log?
[09:19] <jam> mgz: I did. I'm pretty confident about the specific setup, the most interesting part was the '--' issue.
[09:20] <jam> I think for a first pass, we can pick a spot to put it
[09:20] <jam> and if it is important, we can detect '--' in the parameters being set, and split it to that side of a '--' in the commandline.
[09:20] <mgz> that makes sense
[09:21] <jam> mgz: though maas itself doesn't seem to be setting '--', wh
[09:21] <jam> which means that in the immediate term, we don't have to do anything.
[09:21] <jam> if they need to pass "opts more opts -- extra_opts after doubledash"
[09:21] <mgz> it perhaps should, but we can probably punt on it then.
[09:21] <jam> it would just work
[09:28] <dimitern> jam, mgz: do we have the call this morning?
[09:29] <jam> dimitern: not explicitly, though I'm happy to chat with you guys. Shall we just meet up on mumble?
[09:29] <dimitern> sure, I have a headset now :) noise cancelling
[09:30] <jam> mgz: ^^
[09:30] <mgz> er, let me install that, I did the g+ stuff
[09:32] <mgz> er... that won't be happening any time soon
[09:32] <mgz> can we do hangout instead?
[09:39] <jam> mgz: sure, though what happened to you being able to use mumble? (out of curiosity)
[09:40] <mgz> not using the special laptop, due to the screen borkage
[09:41] <mgz> and this borrowed one lacks mumble... or the qt libraries
[09:41] <jam> mgz: sure, I was wondering more about "that won't be happenign any time soon"
[09:41] <mgz> all will become clear :)
[09:42] <jam> dimitern: I seem to have 3 google identities for you, should I use the one with you picture associated with it?
[09:42] <jam> mgz: dimitern: https://plus.google.com/hangouts/_/216f679bd782c69f54ec4960241fd8cedef4340f?authuser=2&hl=en#
[09:42] <dimitern> jam: well, I have the @canonical one - that's it
[09:45] <jam> dimitern: when Martin joined, you suddenly disconnected
[10:22] <mgz> sorry, mistouchpadded the close button
=== jtv1 is now known as jtv
=== mcclurmc is now known as mcclurmc_away
=== nveitch is now known as evilnickveitch
=== dimitern is now known as dimitern_lunch
[12:40] <jam> allenap: poke about the tftp server, I'm trying to figure out if it ever talks to the maas server
[12:40] <jam> Specifically, I realize now why mgz was worried about getting the provisioning server code to get information from the maas server.
[12:40] <jam> Because tftp is where the kernel commandline is getting set
[12:40] <jam> and AFAICT it never talks to the MAAS_URL
[12:40] <jam> so I can import 'auth' and use that stuff, but I want to make sure that is a sane thing to do.
[12:41] <jam> (I don't quite understand the layout given that tftp sits right next to the other worker tasks, maybe they run in the same process?)
[12:45] <jam> rvba: maybe you have an idea about how the tftp service is set up?
[12:48] <rbasak> Are we still supposed to be using quantal for development, or have we switched to raring?
[12:48] <rbasak> I ask because I just tried on quantal and maas-import-squashfs appears broken (in a way that the daily ppa probably fixes)
[12:50] <jam> rbasak: the lp:maas/1.2 branch is meant to be the stable release series for Quantal, I'm not sure about the ppas
[12:50] <rbasak> jam: what about trunk?
[12:51] <jam> rbasak: I don't really know. I would think that it isn't worth breaking Q compatibility yet, but I don't know if there is a reason to diverge.
[12:52] <rbasak> OK
[12:52] <rbasak> I just had to add multiverse for python-selenium, which wasn't a requirement previously, but fair enough
[12:52] <rbasak> Next import-squashfs failed :-(
=== dimitern_lunch is now known as dimitern
[13:01] <dimitern> jam, mgz: how is it going guys?
=== mcclurmc_away is now known as mcclurmc
[13:02] <jam> d
[13:02] <jam> dimitern: I belive mgz is finishing up his lunch. I've gotten the apis exposed, which should unblock your work.
[13:02] <jam> Though I have now hit the tftp wall, and while I can force my way through, I was hoping for feedback from red squad to make sure that was ok to do.
[13:03] <dimitern> jam: I see also your initial MP I depended on is approved now, how about landing it?
[13:07] <jam> dimitern: I marked it as such, jenkins should pick it up and land it shortly
[13:08] <dimitern> jam: ok, sweet - i'll get it from there so I can finish my tests
[13:17] <rvba> jam: I'm not really familiar with the tftp stuff.  But AFAIK, it's a separated twisted process.  It creates 'readers', one reader reads from the local filesystem to serve the images, the other uses the API to generated PXE files on the fly (the url for this is read from pserv.yaml).
[13:22] <jam> rvba: right, I roughly see the code that does it. The problem is it doesn't seem to use any MAAS logic to actually generate the pxe files.
[13:22] <jam> (it doesn't talk to the maasserver for anything, it just grabs the request parameters and uses it to fill out a template file)
[13:22] <jam> at least that I can see.
[13:22] <rvba> jam: it is supposed to talk to the API to generated the PXE file.
[13:24] <jam> rvba: k, it might be, I see a 'generator_url' in there.
[13:26] <jam> ok, found it, I think we can just poke data onto the KernelParameters, which should make things reasonable for us. Yay!
[13:27] <jam> rvba: thanks!
[13:27] <rvba> np
[13:27] <jam> untangling how it was all talking to eachother was a bit tricky
[13:27] <rvba> Indeed, that twisted code is… twisted.
[13:27] <jam> rvba: stuff like having a 'context' object that you can 'get()' data out of
[13:27] <jam> rather than passing parameters
[13:28] <jam> and just sort of magical 'get()' calls.
[13:28] <rvba> Yeah, that makes following what's going on harder.
[13:33] <jam> something seems fishy about the 1.2 series config. 'make run' is failing to startup again, which seems to be an '/etc/bin/rndc.key' failure-to-read
[14:05] <mgz> hm, have not tried make run in 1.2 yet
[14:10] <jam> mgz: I get the feeling people generally don't :).
[14:10] <jam> mgz: https://code.launchpad.net/~jameinel/maas/1.2-pxeconfig-includes-kernel-opts/+merge/133255 is closing the loop to the tftp server
[14:12] <jam> mgz: and now I'm 1 hr past EOD, and my son is right in getting me to stop.
[14:13] <mgz> the son is right
[14:13] <mgz> play time! see you tomorrow :)
[14:13]  * mgz gets on with some branches
[14:37] <roaksoax> robbiew: hwody! is trunk fully operational?
[14:37] <roaksoax> err
[14:37] <roaksoax> sorry :)
[14:37] <roaksoax> rvba: ^^
[14:37] <robbiew> heh
[14:39] <rvba> robbiew: hi, we have to fix bug 1075597 but that's underway.
[14:39] <ubot5> Launchpad bug 1075597 in MAAS "Duplicated prefix in the url used by the CLI" [Critical,Triaged] https://launchpad.net/bugs/1075597
[14:39] <rvba> err
[14:39] <rvba> roaksoax: ^
[14:39] <rvba> Sorry again Robbie :)
[14:39] <roaksoax> rvba: alright, I'd like to upload to raring so I can start preparing the SRU for quantal
[14:40] <roaksoax> rvba: but now I'll look into the precise -> quantal upgrade to see whether i can reproduce the issue or not
[14:40] <rvba> All right.
[14:40] <rvba> jtv is working on a fix for bug 1075597.
[14:40] <ubot5> Launchpad bug 1075597 in MAAS "Duplicated prefix in the url used by the CLI" [Critical,Triaged] https://launchpad.net/bugs/1075597
[14:41] <roaksoax> ok cool
=== matsubara is now known as matsubara-lunch
[16:18] <roaksoax> rvba: what were the consequences of upgrade failure?
[16:18] <roaksoax> rvba: not being able to deploy?
[16:20] <rvba> roaksoax: if you're talking about 1072772, the main symptom was that the DNS config was not being written.  So yes, unable to deploy anything.
[16:20] <roaksoax> rvba: ok cool i'm upgrading now so we'll see what's the outcome
[16:23] <roaksoax> rvba: what else does that affect (without having to enable DNS/DHCP?)
[16:26] <rvba> roaksoax: no task can be fired so: no power_on/power_off task can be fired, the reporting of the boot images cannot happen.
[16:26] <roaksoax> rvba: ack!
[16:35] <roaksoax> rvba: alright, so I just upgraded and the issue didn't appear
[16:36] <roaksoax> rvba: message about images dissappear correctly
[16:36] <roaksoax> rvba: testing power management now
[16:36] <roaksoax> if it works, then DNS should also
[16:41] <roaksoax> rvba: alright, what seems to be the problem now is that tftpd-hpa does not stop
[16:42] <roaksoax> rvba: hence maas-pserv doesn't start
[16:42] <rvba> roaksoax: that looks like another problem.
[16:43] <roaksoax> rvba: python-maas-provisioningserver should probably conflict with tftpd-hpa... but that's weird because maas already does
[16:44] <roaksoax> err maas-cluster-controller
[17:19] <roaksoax> rvba: ok so I upgraded again
[17:19] <roaksoax> rvba: seems to be working just fine
[17:19] <roaksoax> rvba: but the logfile for cluster-celery wasn't created
[17:20] <rvba> roaksoax: and the celery process for the cluster is running?
[17:20] <roaksoax> rvba: nope
=== matsubara-lunch is now known as matsubara
[17:21] <rvba> roaksoax: any error in the upstart log?
[17:22] <roaksoax> rvba: there's no log
[17:22] <rvba> Weird.
[17:22] <roaksoax> rvba: you can access the instance
[17:23] <rvba> Yep, I'm in.
[17:24] <roaksoax> rvba: so nodes enlist and commission
[17:25] <rvba> Nov  7 17:17:47 server-0fd520a0-454d-43b7-8e86-a7d5a4661e8e kernel: [ 1507.296247] init: maas-cluster-celery main process (1229) terminated with status 1
[17:25] <roaksoax> yeah there's no error log though
[17:25] <roaksoax> rvba: what's the logfile that it should have? celery.log?
[17:25] <roaksoax> or celery-cluster.log
[17:26] <rvba> /var/log/maas/celery.log
[17:26] <rvba> roaksoax: I wonder how nodes could be enlisted if pserv is not running.
[17:27] <roaksoax> rvba: i mnanually restarted pserv
[17:27] <rvba> ok
[17:27] <roaksoax> rvba: so I stopped tftpd-hpa and started pserv
[17:30] <roaksoax> rvba: ok so the maas-pserv issue is definitely becuase tftpd-hpa is running
[17:30] <roaksoax> rvba: but maas-cluster-celery is the issue
[17:32] <rvba> roaksoax: I tried to restart maas-cluster-celery and it crashed. maas-cluster-celery main process (8707) terminated with status 1
[17:36] <roaksoax> rvba: ok i think i got it
[17:36] <roaksoax> rvba: i think it is the way how it is sourcing MAAS_URL
[17:36] <roaksoax> or the file that containst it
[17:37] <roaksoax> rvba: ah no
[17:37] <rvba> roaksoax: I ran what the upstart job runs and I got this
[17:37] <rvba> https://pastebin.canonical.com/77847/
[17:38] <roaksoax> rvba: yep, exaclt what i get
[17:38] <rvba> /usr/share/maas/celeryconfig_cluster.py is not on the path.
[17:38] <roaksoax> rvba: yeah I think i saw a bug fixing that
[17:38] <roaksoax> as it was sourcing something else instead
[17:38] <rvba> This must have been caused by a very recent change because it was working fine last week.
[17:39] <roaksoax> indeed
[17:40] <roaksoax> rvba: IIRC, we looked at it last week and it worked
[17:40] <roaksoax> rvba: i mean, we found the root cause
[17:54] <roaksoax> rvba: could this be it? "Another thing that came up is that maas-provision complains about not finding celeryconfig.py, a configuration module that we only use on the region controller.  In a separate branch I'll make the import script select cluster_celeryconfig.py instead."
[17:54] <rvba> No, I don't think this is related.
=== mcclurmc is now known as mcclurmc_away
[17:56] <roaksoax> rvba: i'm pretty sure you debug this couple weeks ago, I came to you and you found the problem
[17:56] <rvba> roaksoax: yeah, this rings a bell indeed… but I can't find what the problem is this time :(
[18:06] <roaksoax> rvba: wasn't it something in /usr/sbin/maas-provision?
[18:08] <rvba> roaksoax: I don't really remember tbh.  Did you manually changed that file?  Looks like it's changed since I checked.
[18:08] <roaksoax> rvba: yeah but set it back to default
[18:09] <roaksoax> rvba: it is not that file, i can't remember what was it
[18:14] <rvba> roaksoax: I think I found the pb.
[18:14] <roaksoax> rvba: what is it?
[18:14] <rvba> roaksoax: /etc/maas/maas_cluster.conf contains the wrong URL.
[18:14] <rvba> MAAS_URL=http://10.55.60.86/
[18:14] <rvba> No, I don't think this is related.I changed it to:
[18:14] <rvba> MAAS_URL=http://10.55.60.86/MAAS/
[18:14] <rvba> Then I restarted the service.
[18:15] <roaksoax> hmmm
[18:15] <rvba> If you look in /var/log/apache2/access.log you will see that it was desperately trying to register.
[18:15] <roaksoax> yeah
[18:15] <roaksoax> let me test this locally real quick
[18:17] <roaksoax> rvba: yeah that seems to be the solution
[18:20] <rvba> roaksoax: We really need to improve the error logging here :)
[18:20] <roaksoax> indeed :)
[18:25] <rvba> roaksoax: filed bug 1076080.
[18:25] <ubot5> Launchpad bug 1076080 in MAAS "No error message is printed anywhere when the cluster controller fails to register itself." [Low,Triaged] https://launchpad.net/bugs/1076080
[18:25] <roaksoax> cool, I filed bug 1076075
[18:25] <ubot5> Launchpad bug 1076075 in maas (Ubuntu) "maas_cluster.conf ends up with the wrong URL after upgrade." [Critical,Confirmed] https://launchpad.net/bugs/1076075
[18:26] <rvba> Cool.
=== mcclurmc_away is now known as mcclurmc
[18:48] <Lele_> hi guys, im running maas from the ppa dailybuiilds on precise
[18:48] <Lele_> when im trying to install maas-dhcp
[18:48] <Lele_> i get
[18:49] <Lele_> Setting up maas-dhcp (0.1+bzr971+dfsg-0+998+75~ppa0~precise1) ...
[18:49] <Lele_> Usage: /usr/bin/django-admin config_master_dhcp [options]
[18:49] <Lele_> Initialize master DHCP settings.
[18:49] <Lele_> a
[18:49] <Lele_> usr/bin/django-admin: error: no such option: --interface
[18:50] <Lele_> dpkg: error processing maas-dhcp (--configure):
[18:50] <Lele_> subprocess installed post-installation script returned error exit status 2
[18:50] <Lele_> Errors were encountered while processing:
[18:50] <Lele_> maas-dhcp
[18:50] <Lele_> and indeed --interface its not a valid django-admin option
[18:50] <Lele_> is this a BUG ?
[18:52] <Lele_> a
[19:01] <Lele_> anyone guys ?
[19:30] <Lele__> i submited a bug for the dailybuild https://bugs.launchpad.net/maas/+bug/1076092
[19:30] <ubot5> Ubuntu bug 1076092 in MAAS "maas-dhcp fails to install on Precise - dailybuild ppa" [Undecided,New]
[19:30] <Lele__> hope someone can take a look at it
=== Guest15779 is now known as dpb___
=== mcclurmc is now known as mcclurmc_away
[20:54] <bigjools> morning
[20:55] <bigjools> roaksoax: hi, want to talk about SRU?
[20:56] <roaksoax> bigjools: yes
[20:56] <roaksoax> but im coming back from lunch
[20:56] <bigjools> roaksoax: np, I am free for an hour
[20:56] <roaksoax> sonif you can give a few minuted will be grear
[20:57] <bigjools> are you drunk? :)
[20:57] <roaksoax> lol i wish it was friday night for me to do so
[20:58] <roaksoax> but im from the ohone
[20:58] <roaksoax> phone
[20:58] <melmoth> on 12.04, is there an easy way to tell maas to use a specific preseed file for _some_ nodes ?
[20:58] <melmoth> the idea would be to use lvm for computes nodes that have 2 drives.
[20:59] <melmoth> right now, maas install computes nodes without touching the 2 drive. So i ended up with 14 drive not being used
[20:59] <melmoth> (actually, 7 drive not being used)
[21:00] <bigjools> melmoth: no, that feature will be in 13.04 though
[21:00] <melmoth> thanks.
[21:06] <roaksoax> melmoth: u would have to ply witth cobbler
[21:08] <roaksoax> bigjools: ready when you are
[21:08] <bigjools> roaksoax: don't encourage people to play with cobbler
[21:09] <bigjools> since we're getting rid of it :)
[21:09] <bigjools> roaksoax: ok so is there anything else special needed for the SRU?
[21:09] <roaksoax> bigjools: I'm not encouraging :) i'm just saying... maybe costumer needs it
[21:09] <roaksoax> bigjools: ok so, yes.
[21:09] <bigjools> so far we have: Backport the Django 1.4 feature we're using and any other new dependencies (need to check those)
[21:10] <bigjools> and test like hell :)
[21:10] <roaksoax> yes
[21:10] <roaksoax> bigjools: so, the plan is basically, finish with those 12.10 bugs
[21:10] <bigjools> and the SRU team agree to this already?
[21:10] <roaksoax> bigjools: and implement the features the qa requrested, plus those missing such as kernel parameters
[21:10] <bigjools> I will make a 12.04 PPA build toda to get the ball rolling
[21:10] <roaksoax> and SRU that to both, quantal, and 12.04
[21:11] <roaksoax> bigjools: i already have precise in PPA
[21:11] <roaksoax> its in experimental, same version we have in quantal
[21:11] <bigjools> roaksoax: the 1.2 branch?
[21:11] <bigjools> ah
[21:11] <bigjools> nice
[21:11] <bigjools> what did you backport?
[21:11] <roaksoax> bigjools: nothing yet, I simply needed that to test upgrade failures
[21:12] <roaksoax> but so far is the django thing
[21:12] <roaksoax> the problem
[21:12] <bigjools> ok, it won't work then :)
[21:12] <roaksoax> and dependencies in universe
[21:12] <roaksoax> bigjools: now, I did want to discuss this
[21:12] <bigjools> universe in 12.04 and main in 13.10 I presume
[21:12] <roaksoax> bigjools: when are you guys looking to finish the SRU-able features?
[21:13] <bigjools> so the "features" were 13.04 only really
[21:13] <roaksoax> bigjools: right, but kernel parameters are needed to be SRUable
[21:13] <bigjools> however given the QA team wanted it in 12.04 I think we should backport those separately
[21:13] <roaksoax> bigjools: uhmmmm maybe
[21:13] <bigjools> so the initial backport should be the bugs in the stabilization milestone
[21:13] <roaksoax> bigjools: well the thing is that we discussed this with smoser and jamespage
[21:14] <bigjools> yeah
[21:14] <bigjools> so I want to minimise risk
[21:14] <roaksoax> bigjools: and we agreed that the best approach was to SRU the QA team features as well
[21:14] <bigjools> if we change too much at once it's not minimised
[21:14] <roaksoax> bigjools: our mplan is to have precise SRU'd by 12.04.2
[21:14] <bigjools> ok
[21:14] <smoser> bigjools, its not minimised :)
[21:14] <bigjools> that's January, plenty of time
[21:14] <smoser> that ship has sailed
[21:14] <roaksoax> yeah
[21:15] <bigjools> smoser: there's relative levels of minimising :)
[21:15] <roaksoax> bigjools: however, note that we will have to make incremental SRU's, so I'm gonna start with quantal
[21:15] <bigjools> so my suggestion would be to SRU the quantal stabilization stuff first, then backport that to precise, then SRU the new features to both
[21:16] <roaksoax> bigjools: my plan is that, sru stabilization, and then sru to precise
[21:16] <roaksoax> bigjools: not backport, SRU
[21:16] <bigjools> roaksoax: perfect
[21:16] <bigjools> yes, I meant SRU
[21:17] <bigjools> but it involves backporting dependencies of course
[21:17] <roaksoax> bigjools: we can't introduce new dependencies
[21:17] <roaksoax> bigjools: so they will have to get shipped with the maas source
[21:17] <bigjools> gaaahhhhhh
[21:17] <bigjools> really?
[21:17] <smoser> what dependencies are we talking about here?
[21:17] <roaksoax> bigjools: i have that covered since yui3, and python-tx-tfpt are
[21:17] <roaksoax> smoser: yui3, python-tx-tftp
[21:18] <smoser> as in those are not available in 12.04 ?
[21:18] <bigjools> correct
[21:18] <smoser> is it just a matter of pulling versions in quantal to 12.04 ?
[21:19] <roaksoax> smoser: both yui3 and python-tx-tftp are two new sources not in 12.04
[21:20] <bigjools> this is also a matter for the security team
[21:20] <bigjools> and who will win? :)
[21:21] <roaksoax> bigjools: us... we have no other option than doing it :)
[21:21] <smoser> roaksoax, given the source of this request, i suggest that new packages to 12.04 is at least possibly negotiable.
[21:22] <roaksoax> smoser: i wasn't aware, nor never heard of being able to introduce new sources into the archive for an older release
[21:22] <smoser> and from security team perspective, if you put yourself in their shoes, and you were going to have to suppor this one way or another...
[21:22] <bigjools> smoser: +1
[21:22] <smoser> which would you rather hvae?  "real packages" or "all shoved inside maas"
[21:23] <bigjools> exactly - security team will need to track stuff shoved into maas
[21:23] <roaksoax> smoser: that's out of the question, definitely real packages, but in terms of policies, I don't think that's covered, is it?
[21:23] <smoser> https://launchpad.net/ubuntu/+source/walinuxagent
[21:23] <smoser> roaksoax, note, that package is not present in 12.04 "release" pocket.
[21:24] <roaksoax> smoser: right, alright, if it is possible
[21:24] <smoser> also note, that i'm not terribly happy with using it as an example, but i'm not aware of others.
[21:24] <roaksoax> then we should do that
[21:24] <smoser> ie, i'm not happy with that crappy package . but it is an example of something that went from "not packaged" to "main" in a SRU
[21:24] <roaksoax> smoser: right,
[21:25] <roaksoax> smoser: i don't really have issues in doing so, i just wasn't aware it was even possible
[21:26] <roaksoax> bigjools: ok so, the plan would be to finish 12.10 stabilization, SRU to quantal, then start looking at precise, sru that
[21:26] <roaksoax> and then SRU raring
[21:26] <roaksoax> as a second mayor SRU
[21:26] <roaksoax> smoser: agreed?
[21:26] <smoser> roaksoax, its not *really* possible
[21:26] <smoser> :)
[21:27] <roaksoax> smoser: right :)
[21:27] <bigjools> roaksoax: yes
[21:27] <smoser> roaksoax, yeah, i think that is a reasonable path. the only change i woudl suggest is
[21:27] <smoser> that you do not wait until "finish 12.10 stabilization" before "start looking at precise"
[21:27] <roaksoax> smoser: oh definitely not, I already have precise packaged
[21:27] <smoser> ie, lets get a ppa functional with what is in quantal now.
[21:27] <smoser> right.
[21:28] <roaksoax> smoser: just need to pull in django fix
[21:28] <smoser> bigjools, are you just awake because you're stuck on europe time?
[21:28] <roaksoax> and now split the other dependencies into their own packages
[21:28] <bigjools> smoser: pretty much
[21:28] <bigjools> smoser: body clock is screwed to hell
[21:28] <bigjools> smoser: was up at 4am
[21:28] <bigjools> sun comes up at 5
[21:28] <smoser> roaksoax, we should consult security team to see what they suggest on the new dependencies.
[21:29] <roaksoax> smoser: will do
[21:29] <bigjools> then my twins wake up ... not much hope of sleep after that :)
[21:29] <roaksoax> smoser: the only real problem would be yui3, which is a new source that really replaces yui
[21:29] <smoser> and point out to them that a.) we really, really want SRU of 12.10 maas to 12.04, and b.) walinux did it, so maybe we can too
[21:29] <roaksoax> so they won't be co-installable IIRC
[21:30] <smoser> roaksoax, hm.. yeah, i dont know. probably can be sorted out.
[21:31] <roaksoax> alright, i'll talk to them and then sort things out
[21:31] <roaksoax> them = security team
[21:33] <bigjools> roaksoax: great, I'll catch up with you next week about that then (I am off work Friday)
[21:36] <roaksoax> bigjools: same here
=== mcclurmc_away is now known as mcclurmc
=== mcclurmc is now known as mcclurmc_away