=== jfarschman is now known as MilesDenver === CyberJacob is now known as CyberJacob|Away === jfarschman is now known as MilesDenver === CyberJacob|Away is now known as CyberJacob === jfarschman is now known as MilesDenver [02:10] Oops: the development environment is broken. [02:11] 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] jtv: yeah rvb filed a bug about that [02:22] another critical that needs fixing.... we have so many all of a sudden [02:22] btw: https://code.launchpad.net/~julian-edwards/maas/update-mac-to-cluster-when-updating-leases/+merge/232961 [02:54] bigjools: approved. [03:00] jtv: thanks. BTW I am reviewing Gavin's branch [03:00] I forgot to mark it [03:00] Brave. [03:00] I feel follhardy [03:00] foolhardy, too [03:03] It's all in the follicles. === jfarschman is now known as MilesDenver [03:24] bigjools: need pre-imp... are you free? [03:24] jtv: not just yet, trying to finish reviewing gavin's branch and then I need to eat [03:24] OK. [03:24] I'll fill the time with something useful. [03:24] I'll ping you when I can [03:25] jtv: https://bugs.launchpad.net/maas/+bug/1363913 and https://bugs.launchpad.net/maas/+bug/1362693 [03:25] :) [03:25] Ubuntu bug 1363913 in MAAS "Impossible to remove last MAC from network in UI" [Undecided,New] [03:25] Ubuntu bug 1362693 in MAAS "MAAS is providing 2 IP's even if there's only 1 NIC in the network" [Undecided,New] [03:25] Sounds fun. [03:26] bug 1330765 [03:26] bug 1330765 in MAAS "If start_nodes() fails, it doesn't clean up after itself." [High,Triaged] https://launchpad.net/bugs/1330765 [03:26] Why are you listing bugs at me? [03:26] ignore that one [03:26] that was for me [03:27] I'm too lazy to go to LP === jfarschman is now known as MilesDenver [04:44] jtv: ok call? [04:44] Yay === jfarschman is now known as MilesDenver [05:51] jtv: alert [05:51] ? [05:51] GPG home needed on maasserver as well :( [05:51] see src/maasserver/start_up.py line 95 [05:51] Is that a problem though? We can have the Makefile set it on both sides. [05:52] And the maasserver can import it from the provisioningserver, no problem. [05:52] which imports from provisioningserver.upgrade_cluster, yegads [05:56] the dev ui is now almost useless without a cluster and image data :( [05:59] The work I'm doing now should put us in a position to provide that though. [05:59] Because a branch will have a natural place to put boot resources etc. [05:59] even after blake's changes? [05:59] Oh, does he still put them in /var/lib/maas..? [05:59] no, they're going to be in the DB [06:00] Well never mind that then. [06:00] we could just fudge the sample data for now === jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver [07:22] 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] Because signal handlers may reconfigure DNS/DHCP, and any errors while doing that ought to be displayed. [07:25] 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] Yeah. It's a bit ugly though isn't it? [07:26] A tad. But AFAIK it's the only way. [07:26] jtv: I /seem/ to remember we've used this technique before… let me see if I can find it in the code. [07:26] We do have the "register a message on the current page whatever it is" part. [07:27] Another way to do it would be to make it run asynchronously (somehow) and register component errors. [07:27] Or, we could move the calls out of the signal handlers and into the forms. [07:28] If it's possible, moving things like that into the forms seems like the cleanest way to do it. [07:29] 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] If you take the error backchannel into account, at least. [07:45] Anyone able to review https://code.launchpad.net/~jtv/maas/bug-1363900/+merge/232982 ? [07:46] jtv: sure, I'll take it. [07:46] Thanks. [07:49] 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] rvba: provisioningserver. :) [07:51] Can't import anything django-ey from there — that rules out the django configs as well, right? [07:51] Right. [07:51] It's annoying, but we're ditching the celery config so we need something in its place. [07:52] It seems to me that every time we ditch a part of Celery we introduce something more hacky instead. [07:54] 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] You do a "make run" and you basically get a filesystem root in the "run" directory. [07:54] Right. [07:55] And: if we stick to the pattern, we lose some side effects. [07:59] jtv: in get_path's docstring you say the call has side effects… which side effects? [07:59] Reading the environment and the filesystem. [07:59] Ah, not the filesystem — the current working directory. [08:00] They're not very big side effects, but that's a slippery slope. [08:00] Is reading the environment considered a dangerous side effect? [08:00] No, just a side effect — the sort of thing we should avoid doing during import. [08:01] Reading the current working directory? I don't see it, what am I missing? [08:01] It's implicit in the abspath. [08:01] As in, "reading what the current working directory is," not "reading the directory listing." [08:01] Really? I didn't know that. [08:02] Oh, I see, because you're using '.' [08:03] 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] (Not read the working directory's contents, but read what the cwd is.) [08:04] Very minor side effects, but we've been quietly accepting side effects and it leads to more. === jfarschman is now known as MilesDenver [08:15] jtv: branch approved with a couple of minor suggestions. [08:15] Thanks! [08:30] 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] allenap: it doesn't have per-env settings [08:30] allenap: what bigjools said === jfarschman is now known as MilesDenver [09:09] allenap: there were a couple of critical pserv/rpc bugs [09:09] one was where if it starts before the region, it never connects [09:16] bigjools: Ah yes, I’ll take a look at that. [09:22] allenap: It would need a 1.6 backport as well === jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver === dannf` is now known as dannf === jfarschman is now known as MilesDenver [14:08] 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] 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] Ubuntu bug 1307779 in MAAS "fallback from specific to generic subarch broken" [Critical,Fix released] [14:21] i saw that this bug is solved in 1.6 but i can't find that package anywhere in the repo [14:21] any other suggestions? === cmagina_ is now known as cmagina_airport === cmagina_airport is now known as cmagina_mobile [14:37] rvba: Okay, it’s out of your hands, no worries. [14:42] rvba: https://code.launchpad.net/~blake-rouse/maas/fix-1364062/+merge/233070 [15:25] blake_r: I like the commit message of revision 2874 on https://code.launchpad.net/~blake-rouse/maas/fix-1364062/+merge/233070 [15:25] rvba: haha [15:26] rvba: forgot to link the bug with --fixes [15:26] rvba: thanks for the review [15:26] My pleasure. [15:33] rvba, how was your flight back? [15:33] newell: horribly bumpy. [15:33] 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] rvba, ah that sucks [15:34] Hopefully you both didn't feel like it was then last flight of your life [15:34] newell: okay, thanks [15:34] s/then/the [15:34] newell: well, yes, at some point I did. [15:35] 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] newell: yeah, I could use you help on the node event log work. [15:53] rvba: didnt we use to get a traceback on api errors, finding errors in tests, is really hard now [15:53] allenap: ^ [15:54] 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] rvba: can we change that so we get tracebacks when running tests? [15:54] rvba: like debug=True return traceback [15:55] blake_r: I guess we could do that… what kind of errors are you interested in? [15:56] rvba: i have something wrong in my code, I am running a unit test [15:56] rvba: all i get is a oneliner says the exception error [15:56] rvba: i would like to know where, so I can find it [15:56] rvba: stack tracing through django code to find it takes forever [15:56] rvba: i just want stack trace back [15:56] rvba: on django side [15:57] blake_r: sure, but what *kind* of errors are you interested in? [15:57] You'll still get a stracktrace for a real error. [15:57] rvba: 'NoneType' object has no attribute 'items' [15:57] rvba: that would be a real error, that is all I get [15:57] Not for a BadRequest error anymore. Which makes sense, because it's not an error even if internally it uses exceptions. [15:58] rvba: its a 500 error [15:58] blake_r: okay, this is a bug then. [16:02] rvba: https://bugs.launchpad.net/maas/+bug/1364481 [16:02] Ubuntu bug 1364481 in MAAS "http 500 error doesn't contain a stack trace" [Critical,Confirmed] [16:02] blake_r: cool, I'll take care of it. [16:02] rvba: thanks [16:14] blake_r: https://code.launchpad.net/~rvb/maas/traceback-error-500/+merge/233086 [16:16] rvba: line 8-9 on the diff? dont you need that? [16:17] blake_r: no, it's integrated into ExceptionMiddleware now. [16:17] rvba: okay [16:46] 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 [16:46] Ubuntu bug 1307779 in MAAS "fallback from specific to generic subarch broken" [Critical,Fix released] === jfarschman is now known as MilesDenver === CyberJacob is now known as CyberJacob|Away === CyberJacob|Away is now known as CyberJacob === roadmr is now known as roadmr_afk [18:20] 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 === jfarschman is now known as MilesDenver === roadmr_afk is now known as roadmr === CyberJacob is now known as CyberJacob|Away