[02:10] <jtv> Oops: the development environment is broken.
[02:11] <jtv> Cluster won't start up because the startup code tries to create GNUPGHOME, which is now hard-coded to its production location in /var/lib.
[02:21] <bigjools> jtv: yeah rvb filed a bug about that
[02:22] <bigjools> another critical that needs fixing.... we have so many all of a sudden
[02:22] <bigjools> btw: https://code.launchpad.net/~julian-edwards/maas/update-mac-to-cluster-when-updating-leases/+merge/232961
[02:54] <jtv> bigjools: approved.
[03:00] <bigjools> jtv: thanks. BTW I am reviewing Gavin's branch
[03:00] <bigjools> I forgot to mark it
[03:00] <jtv> Brave.
[03:00] <bigjools> I feel follhardy
[03:00] <bigjools> foolhardy, too
[03:03] <jtv> It's all in the follicles.
[03:24] <jtv> bigjools: need pre-imp... are you free?
[03:24] <bigjools> jtv: not just yet, trying to finish reviewing gavin's branch and then I need to eat
[03:24] <jtv> OK.
[03:24] <jtv> I'll fill the time with something useful.
[03:24] <bigjools> I'll ping you when I can
[03:25] <bigjools> jtv: https://bugs.launchpad.net/maas/+bug/1363913 and https://bugs.launchpad.net/maas/+bug/1362693
[03:25] <bigjools> :)
[03:25] <jtv> Sounds fun.
[03:26] <bigjools> bug 1330765
[03:26] <jtv> Why are you listing bugs at me?
[03:26] <bigjools> ignore that one
[03:26] <bigjools> that was for me
[03:27] <bigjools> I'm too lazy to go to LP
[04:44] <bigjools> jtv: ok call?
[04:44] <jtv> Yay
[05:51] <bigjools> jtv: alert
[05:51] <jtv> ?
[05:51] <bigjools> GPG home needed on maasserver as well :(
[05:51] <bigjools> see src/maasserver/start_up.py line 95
[05:51] <jtv> Is that a problem though?  We can have the Makefile set it on both sides.
[05:52] <jtv> And the maasserver can import it from the provisioningserver, no problem.
[05:52] <bigjools> which imports from provisioningserver.upgrade_cluster, yegads
[05:56] <bigjools> the dev ui is now almost useless without a cluster and image data :(
[05:59] <jtv> The work I'm doing now should put us in a position to provide that though.
[05:59] <jtv> Because a branch will have a natural place to put boot resources etc.
[05:59] <bigjools> even after blake's changes?
[05:59] <jtv> Oh, does he still put them in /var/lib/maas..?
[05:59] <bigjools> no, they're going to be in the DB
[06:00] <jtv> Well never mind that then.
[06:00] <bigjools> we could just fudge the sample data for now
[07:22] <jtv> rvba, this looks like a question for you: is there, or should there be, a way for a signal handler to find the web request, if any, whose processing led to the firing of the signal?
[07:22] <jtv> Because signal handlers may reconfigure DNS/DHCP, and any errors while doing that ought to be displayed.
[07:25] <rvba> jtv: there is no direct (as in built-in) way AFAIK.  The first thing that comes to mind is to make the current request available by storing it somewhere (i.e. as a global object) and letting anything (including signal callbacks) find it.
[07:26] <jtv> Yeah.  It's a bit ugly though isn't it?
[07:26] <rvba> A tad.  But AFAIK it's the only way.
[07:26] <rvba> jtv: I /seem/ to remember we've used this technique before… let me see if I can find it in the code.
[07:26] <jtv> We do have the "register a message on the current page whatever it is" part.
[07:27] <jtv> Another way to do it would be to make it run asynchronously (somehow) and register component errors.
[07:27] <jtv> Or, we could move the calls out of the signal handlers and into the forms.
[07:28] <rvba> If it's possible, moving things like that into the forms seems like the cleanest way to do it.
[07:29] <jtv> Yeah.  In the long run I'd love to make it asynchronous, where we just set a "dirty" flag to say "this needs reconfiguring," but that sounds like a major project.
[07:29] <jtv> If you take the error backchannel into account, at least.
[07:45] <jtv> Anyone able to review https://code.launchpad.net/~jtv/maas/bug-1363900/+merge/232982 ?
[07:46] <rvba> jtv: sure, I'll take it.
[07:46] <jtv> Thanks.
[07:49] <rvba> jtv: I wonder why you felt we needed another mechanism to override variables in a dev env.  Don't we have a separate config for this (src/maas/development.py)?
[07:50] <jtv> rvba: provisioningserver.  :)
[07:51] <jtv> Can't import anything django-ey from there — that rules out the django configs as well, right?
[07:51] <rvba> Right.
[07:51] <jtv> It's annoying, but we're ditching the celery config so we need something in its place.
[07:52] <rvba> It seems to me that every time we ditch a part of Celery we introduce something more hacky instead.
[07:54] <jtv> I wouldn't really know — I've been assigned to other work while this was going on.  But I hope this can replace a bunch of it with a bit of system to it.
[07:54] <jtv> You do a "make run" and you basically get a filesystem root in the "run" directory.
[07:54] <rvba> Right.
[07:55] <jtv> And: if we stick to the pattern, we lose some side effects.
[07:59] <rvba> jtv: in get_path's docstring you say the call has side effects… which side effects?
[07:59] <jtv> Reading the environment and the filesystem.
[07:59] <jtv> Ah, not the filesystem — the current working directory.
[08:00] <jtv> They're not very big side effects, but that's a slippery slope.
[08:00] <rvba> Is reading the environment considered a dangerous side effect?
[08:00] <jtv> No, just a side effect — the sort of thing we should avoid doing during import.
[08:01] <rvba> Reading the current working directory?  I don't see it, what am I missing?
[08:01] <jtv> It's implicit in the abspath.
[08:01] <jtv> As in, "reading what the current working directory is," not "reading the directory listing."
[08:01] <rvba> Really?  I didn't know that.
[08:02] <rvba> Oh, I see, because you're using '.'
[08:03] <jtv> Actually I think that one will be a simple text processing exercise.  But calling abspath with a relative path makes it get the current working directory.
[08:03] <jtv> (Not read the working directory's contents, but read what the cwd is.)
[08:04] <jtv> Very minor side effects, but we've been quietly accepting side effects and it leads to more.
[08:15] <rvba> jtv: branch approved with a couple of minor suggestions.
[08:15] <jtv> Thanks!
[08:30] <allenap> jtv, rvba: There’s pserv.yaml, which is really not hacky (it has a _schema_). Modifying it from packaging though… that’s hacky.
[08:30] <bigjools> allenap: it doesn't have per-env settings
[08:30] <rvba> allenap: what bigjools said
[09:09] <bigjools> allenap: there were a couple of critical pserv/rpc bugs
[09:09] <bigjools> one was where if it starts before the region, it never connects
[09:16] <allenap> bigjools: Ah yes, I’ll take a look at that.
[09:22] <bigjools> allenap: It would need a 1.6 backport as well
[14:08] <rvba> allenap: about my bug-1359169 branch (thanks for the review btw), I'm not sure I can move away from using exception.message because piston and oauth both rely on this pretty heavily it seems.
[14:21] <ramonskie> hi i have upgraded to trusty on my cluster controller with maas 1.5.2 installed and i stumbled on this bug https://bugs.launchpad.net/maas/+bug/1307779
[14:21] <ramonskie> i saw that this bug is solved in 1.6 but i can't find that package anywhere in the repo
[14:21] <ramonskie> any other suggestions?
[14:37] <allenap> rvba: Okay, it’s out of your hands, no worries.
[14:42] <blake_r> rvba: https://code.launchpad.net/~blake-rouse/maas/fix-1364062/+merge/233070
[15:25] <rvba> blake_r: I like the commit message of revision 2874 on https://code.launchpad.net/~blake-rouse/maas/fix-1364062/+merge/233070
[15:25] <blake_r> rvba: haha
[15:26] <blake_r> rvba: forgot to link the bug with --fixes
[15:26] <blake_r> rvba: thanks for the review
[15:26] <rvba> My pleasure.
[15:33] <newell> rvba, how was your flight back?
[15:33] <rvba> newell: horribly bumpy.
[15:33] <newell> blake_r, I am fixing up what I have for the curtin-maas-install stuff and then I will push so you can take a look
[15:33] <newell> rvba, ah that sucks
[15:34] <newell> Hopefully you both didn't feel like it was then last flight of your life
[15:34] <blake_r> newell: okay, thanks
[15:34] <newell> s/then/the
[15:34] <rvba> newell: well, yes, at some point I did.
[15:35] <newell> rvba, roaksoax mentioned he wanted me to work with you on whatever you are doing.  Not sure what that is or if you talked with him about this or not.
[15:36] <rvba> newell: yeah, I could use you help on the node event log work.
[15:53] <blake_r> rvba: didnt we use to get a traceback on api errors, finding errors in tests, is really hard now
[15:53] <blake_r> allenap: ^
[15:54] <rvba> blake_r: yes, now we only get tracebacks for real errors, not validation errors etc which, although handled internally as exceptions, are not errors per-se.
[15:54] <blake_r> rvba: can we change that so we get tracebacks when running tests?
[15:54] <blake_r> rvba: like debug=True return traceback
[15:55] <rvba> blake_r: I guess we could do that… what kind of errors are you interested in?
[15:56] <blake_r> rvba: i have something wrong in my code, I am running a unit test
[15:56] <blake_r> rvba: all i get is a oneliner says the exception error
[15:56] <blake_r> rvba: i would like to know where, so I can find it
[15:56] <blake_r> rvba: stack tracing through django code to find it takes forever
[15:56] <blake_r> rvba: i just want stack trace back
[15:56] <blake_r> rvba: on django side
[15:57] <rvba> blake_r: sure, but what *kind* of errors are you interested in?
[15:57] <rvba> You'll still get a stracktrace for a real error.
[15:57] <blake_r> rvba: 'NoneType' object has no attribute 'items'
[15:57] <blake_r> rvba: that would be a real error, that is all I get
[15:57] <rvba> Not for a BadRequest error anymore.  Which makes sense, because it's not an error even if internally it uses exceptions.
[15:58] <blake_r> rvba: its a 500 error
[15:58] <rvba> blake_r: okay, this is a bug then.
[16:02] <blake_r> rvba: https://bugs.launchpad.net/maas/+bug/1364481
[16:02] <rvba> blake_r: cool, I'll take care of it.
[16:02] <blake_r> rvba: thanks
[16:14] <rvba> blake_r: https://code.launchpad.net/~rvb/maas/traceback-error-500/+merge/233086
[16:16] <blake_r> rvba: line 8-9 on the diff? dont you need that?
[16:17] <rvba> blake_r: no, it's integrated into ExceptionMiddleware now.
[16:17] <blake_r> rvba: okay
[16:46] <ramonskie> i have upgraded to trusty on my cluster controller and now i stumbled on this error https://bugs.launchpad.net/maas/+bug/1307779 so it seems that i need to upgrade to maas 1.6 but i can't find the package
[18:20] <gQuigs> anyone know if there is any way to get maas to dump all data about it's environment?  sosreport tries to collect "maas dumpdata" but that never works