=== matsubara is now known as matsubara-afk
[03:41] <shang> Hi All, I have 2 questions. 1: Why do we need to manually download the meta file for isos? Is there a reason behind not make it automatically download it at installation time?
[03:42] <shang> 2. we tried to run: sudo maas-import-pxe-files, but failed. I noticed that: https://maas.ubuntu.com/images/query/precise/ephemeral/released-dl.current.txt is not accessible
[03:43] <ThiagoCMC> firewall rules?! this machine can browse the web?
[03:44] <shang> yup, I just tried it on my computer: This page does not exist yet. You can create a new empty page, or use one of the page templates.
[03:45] <ThiagoCMC> weird...   :-/
[03:45] <ThiagoCMC> I just run this command few hours ago...
[03:49] <shang> does that work on your browser?
[03:50] <freeflyi1g> ThiagoCMC: but why does import-pxe-file need access to that page?
[03:51] <ThiagoCMC> Have no idea... Sorry but, I'm still learning about MaaS...   =(
[03:51] <ThiagoCMC> I'm newbie here...    =P
[03:59] <freeflyi1g> ThiagoCMC: no worries, we're in the same boat :)
[04:06] <ThiagoCMC> ^^
[04:12] <shang> sorry for the noise, the link works now
[04:13] <shang> I can download the files expected :)
[04:14] <bigjools> o/ lifeless
[04:16] <lifeless> bigjools: o/
[04:28] <ThiagoCMC> bigjools, hi! I find more places telling to use two network interfaces with MaaS (I think...)... Look: http://www.ubuntu.com/cloud/private-cloud/reference-architecture "Each nova compute..." and - https://wiki.edubuntu.org/SecurityTeam/TestingOpenStack ...
[04:29] <ThiagoCMC> I don't know if it is related but, it isn't a requirement, right?!
[04:29]  * bigjools looks
[04:29] <bigjools> I don't know about those, they are not maas-related
[04:30] <ThiagoCMC> ok
[04:30] <bigjools> I suspect it's for firewalling
[04:30] <bigjools> so maybe a recommended setup but not necessarily required
[04:30] <ThiagoCMC> Gotcha!
[08:51] <mgz> hm, we should probably have a tags index page
[09:00] <allenap> rvba: Do we pass a queryset to Piston? If so, could we patch the iterator() method for that single queryset, so that it does prefetching? It's a hack, but it's quick as a proof of how to fix the problem.
[09:01] <rvba> allenap: we pass a queryset of nodes but then the serialization inspect them one by one to get the related MAC addresses.
[09:01] <rvba> That's what is generating the queries.
[09:03] <rvba> allenap: does that make sense?
[09:03] <allenap> rvba: I guess I don't know enough/anything about how Django does prefetching. In Storm that would work, for example, because it the prefetch would pull in the related rows.
[09:04] <rvba> allenap: yeah, but there is no caching like that in Django.
[09:04] <allenap> and, depending on how they're related, it could get them from cache.
[09:04] <allenap> Right, okay.
[09:13] <jtv> rvba: just noticed something weird...  you made ip_range_low & ip_range_high non-unique because they can be null?
[09:14] <jtv> Does that mean that we're still storing "null" IP addresses as empty strings?  :(
[09:14] <rvba> jtv: yes
[09:14] <jtv> Bugger.  Silly nonsense.
[09:15] <jtv> If we could store them as proper IP addresses, which can be properly null in the database, this wouldn't be an issue.
[09:15] <jtv> (because (null = null) -> null)
[09:18] <rvba> Anyone up for a pre-imp about this performance thing?  I think I possible solution.
[09:18] <rvba> jtv: allenap ^ ?
[09:18] <rvba> I see* a possible solution
[09:20] <jtv> rvba: gimme a sec
[09:29] <jam> rvba: if you would like
[09:31] <jam> rvba: I mentioned in the bug that I think you can pre-iterate the queryset by just calling list() on it.
[09:31] <jam> which I think works around the piston.iterator() issue.
[09:47] <rvba> jam: I'll try that before I go on with my much complex plan.
[09:51] <rvba> jam: this does not seem to work.  Because the .iterator() is not problematic on the nodes but on the related MAC addresses.
[09:52] <jam> rvba: so if it as big issue, the worst case is to return HTTPResponse(json.dumps(stuff))
[09:52] <jam> but that is a pretty big overhaul to get around piston.
[09:53] <rvba> But it also means we don't have control over the fields returned.
[09:53] <rvba> I think I have a solution which simply involve creating a very small specialized emitter.
[09:53] <rvba> involves*
[09:54] <jam> rvba: well dumps(stuff) you have full control over what goes into 'stuff'. :)
[09:54] <rvba> Sure, but I mean you have to fabricate the objects by hand.
[09:54] <rvba> That means computing the resource_uri stuff by hand etc.
[09:55] <jam> rvba: looking at the piston Emitter level of local function nested makes my eyes bleed just a little bit :)
[09:55] <jam> nesting.
[09:55] <jam> rvba: so the tag_names change, feel free to just land that one.
[09:55] <rvba> jam: Yeah, I had the same reaction :)
[09:56] <jam> well, land it with a '.only()'
[09:56] <jam> so it doesn't have to load all tag columns just for the one attribute.
[09:56] <rvba> jam: I'll do it, but first, I'll get that specific emitter done.
[10:02] <rvba> jtv: It looks like the prefetch_related stuff is intelligent enough to restrict the queries it issues if the "original" query is restricted.
[10:03] <rvba> jtv: unrestricted: http://paste.ubuntu.com/1286632/ / restricted: http://paste.ubuntu.com/1286633/
[10:04] <rvba> jtv: here is the code that generates these queries: http://paste.ubuntu.com/1286635/
[10:04] <rvba> jam: with or without the '[:3]' bit of course
[10:04] <rvba> err, jtv
[10:05] <jam> rvba: right. Because it doesn't do the prefetch until it has fetched the list of nodes, because it needs their ids to do the other fetch.
[10:09] <jtv> otp
[10:11]  * jtv shakes fist at long, unwrapped lines
[10:12] <jtv> Ah OK
[10:15] <rvba> jam: now I need to find a way to override a method that is deeply buried.
[10:15] <rvba> http://paste.ubuntu.com/1286648/
[10:16] <rvba> I'm talking about the horrible nesting you mentioned.
[10:16] <jam> rvba: that is *really* hard to do, because the actual 'I_want_to_ovrride_this' doesn't exist until after the def runs.
[10:17] <rvba> Good point… what a mess.
[10:34] <jtv1> Oops.  Filesystem corruption again.  :(
[10:35] <jtv1> Better reboot & manually fsck.
[10:45] <rbasak> rvba: have you seen this before? http://paste.ubuntu.com/1286685/
[10:45] <rbasak> Nothing has changed that I'm aware of so I presume I've inadvertently changed something as it worked before
[10:45] <rbasak> locale.getdefaultlocale() returns None
[10:45] <rvba> rbasak: o_O, never seen that before.
[10:46] <rbasak> Ah
[10:46] <rbasak> The preseed I'm using might have changed yesterday
[10:46] <rbasak> (on the MAAS server)
[10:46] <rbasak> It's now "C"
[10:47] <mgz> that's some bad code in django...
[10:47] <rbasak> "LANG=en_GB.UTF-8 maas createsuperuser" works
[10:47] <mgz> the locale really should be C.utf8 though
[11:08] <rbasak> https://code.djangoproject.com/ticket/16017
[11:08] <ubot5> Django bug 16017 in Core (Management commands) "createsuperuser fails if Python can't detect default locale" [Normal,Closed]
[11:08] <rbasak> Looks like it's not just me
[12:57] <jam> rvba: do you know the speed of updating the dailybuilds? If I land something now, is it likely to be in the build tomorrow? or would I have to wait one more day?
[12:57] <mgz> today is a rather unusual day...
[12:58] <mgz> probably in a good way though, most of the q work is done and r is not yet open
[13:00] <rvba> jam: I think it will be there tomorrow.  But apparently, you can request the build to happen manually.
[13:00] <rvba> I just tried it, it seems to work.
[13:00] <rvba> (I usually use my own ppa)
[13:01] <rvba> jam: there is a 'request build' button on https://code.launchpad.net/~julian-edwards/+recipe/maas-daily.
[13:01] <rvba> If you're not allowed to do that (?) I can trigger the build for you.
[13:03] <jam> k
[13:14] <mgz> hm, jam it seems your gzip branch is missing the actual middleware?
[13:14] <jam> mgz: did that not get pushed?
[13:14] <jam> hmm...
[13:15] <jam> mgz: src/maas/settings.py should have django.middleware.gzip.GzipMiddleware
[13:15] <jam> I see it here.
[13:15] <mgz> right, but jenkins complains that it doesn't exist
[13:15] <mgz> might be some djangoy weirdness?
[13:16] <jam> mgz: no, capitalization typo
[13:17] <jam> the name is GzipFile, but GZipMiddleware
[13:17] <jam> I tend not to run 'make test' each time, I should do it more often.
[13:21] <jam> mgz: thanks for noticing. Also, as I am likely to not be around much tomorrow, can you keep an eye on dimitern, I'd hate for him to run amok on his first week :)
[13:22] <dimitern> :)
[13:22] <mgz> :)
[13:22] <jam> mgz: we've also been missing you on mumble today, but on Monday, we'll all see eachother in person anyway.
[13:23] <mgz> yeah, not the best environment for mumbling this unfortunately
[13:23] <mgz> I'm not around til tuesday evening, but am looking forward to it.
[13:23] <mgz> I think it's only managery things the first two days?
[13:26] <rvba> I think so, I'll arrive on Tuesday evening as well.
[13:46] <matsubara> mgz, that worked, thanks! :-)
[13:47] <mgz> :)
[14:33] <dimitern> I pushed my first change! :) can I bug someone to review it please?
[14:34] <dimitern> mgz: :) ^
[14:34] <mgz> having a look
[14:35] <dimitern> only for the docstring I'm not sure what exactly to describe... not aware of the full process
=== matsubara is now known as matsubara-lunch
[16:02] <allenap> mgz: Ah, sorry, I beat you to it again :-/
[16:04] <mgz> allenap: no problem :)
[16:16] <rbasak> I'm concerned about bug 1068086. Can anyone reproduce on amd64?
[16:16] <ubot5> Launchpad bug 1068086 in MAAS "juju fails to deploy with MAAS by default" [Undecided,New] https://launchpad.net/bugs/1068086
[16:16]  * rbasak notes the irony in the last four digits of that bug number
[16:21] <mgz> rbasak: I've seen something along those lines before, but am failing to search up recollection
[16:33] <mgz> rbasak: need to go now, but will try to dig into it tomorrow if none of the americans get there first
[16:36] <rbasak> thanks mgz
=== matsubara-lunch is now known as matsubara
=== matsubara is now known as matsubara-brb
=== matsubara-brb is now known as matsubara
=== lifeless_ is now known as lifeless