[03:23] <bigjools> jtv: was there a good reason to optimise the lease sending to the region so it didn't send them if there were no changes?
[03:23] <bigjools> I ask because of this bug with static IPs; if the leases are sent before the node is in maas then the cluster_interface link is never made
[03:24] <bigjools> so I have two choices to fix this: 1. send all leases every time, 2. add a separate job to parse the in-DB ones
[03:24] <bigjools> well "parse", read and apply the link I mean
[03:30] <jtv> bigjools: the reason was just generic worry about size, not any problem that we encountered in practice.
[03:31] <jtv> Is this what's been causing the bug where nodes didn't get static addresses in CI?
[03:32] <jtv> It's not a matter of checking at MACAddress creation time whether a lease existed?
[03:49] <bigjools> jtv: that would be a third solution yes
[05:29] <bigjools> jtv: ok, I did it that way: https://code.launchpad.net/~julian-edwards/maas/always-send-leases/+merge/234052
[06:16] <jtv> bigjools: funny how that problem pattern keeps cropping up in software.
[06:17] <bigjools> jtv: which one?
[06:17] <jtv> Having to detect that a combination of two events have occurred both when one occurs and when the other occurs.
[06:17] <bigjools> ah yes
[06:18] <bigjools> I thought about using signals, and then I slapped myself in the face and woke up
[09:01] <gmb> allenap: Branch: lp:~gmb/maas/port-add-virsh-to-rpc ; bin/test.maas maasserver.models.tests.test_nodegroup produces http://paste.ubuntu.com/8307588/
[09:01] <gmb> (this is the "Twisted is twisting my melon" problem, not the isolation problem.")
[09:02] <allenap> gmb: /me looks
[09:02] <gmb> allenap: The "expected to be called…" thing I understand; it's the __call__ takes 2 arguments bit that I'm fuzzy on.
[09:04] <allenap> gmb: In NodeGroup.add_virsh you need to use keywords for all arguments (other than the command) when using the client.
[09:06] <gmb> allenap: AAAAAAAAAAAAAH
[09:06] <gmb> allenap: Can we improve that error, or is that upstream (looks like upstream…)
[09:07] <jtv> bigjools: I need to get a node's StaticIPAddress objects, but Node.static_ip_addresses returns address strings, not the objects.  Would it make sense to split out the part that returns StaticIPAddress objects?
[09:08] <bigjools> jtv: no, one moment OTP
[09:15] <caribou> jtv: remember my rsyslog query yesterday ? The MP for it is in Bug #1346703
[09:17] <allenap> gmb: We can improve that error; I’ll sort it out.
[09:21] <gmb> allenap: Thanks. I was also missing a .wait(), but the error for that is *amazingly* helpful. I'm going to assume you wrote the code that generates it, so _thank you_.
[09:22] <jtv> caribou: that explains why I didn't see it on the reviews list — we normally work against the upstream branches!
[09:22] <jtv> In this case, that'd be lp:~maas-maintainers/maas/packaging
[09:22] <caribou> jtv: I know, but the fix is on the debian packaging files which are not on the dev branch
[09:22] <jtv> We have separate upstream branches for those  ^
[09:23] <caribou> jtv: ah, so you have a specific branch for the packaging; want me to do the MP against this branch ?
[09:23] <jtv> Yes please!
[09:23] <jtv> You can probably just hit Resubmit.
[09:26] <caribou> jtv: sure, will do right now
[09:26] <bigjools> jtv: ok sorry I misread, yes, split it out
[09:26]  * bigjools back later
[09:26] <caribou> jtv: I *manually* tested it on Utopic; seems to work fine
[09:26] <caribou> jtv: i.e. I rebuilt the packages & installed the debs
[09:28] <jtv> Thanks bigjools
[09:28] <jtv> caribou: if you check out lp:maas and cd into it, you can just run "make package" — will create packages in ../build-area
[09:28] <jtv> (Bit weird as a location, but otherwise very convenient)
[09:29] <caribou> jtv: good to know. I build so many pkg that debuild -S && sbuild are my friends
[09:29] <caribou> jtv: ok, I just resubmitted to lp:~maas-maintainers/maas/packaging
[09:30] <caribou> jtv: regarding Bug #1367266, want me to do a MP for this one as well ?
[09:31] <caribou> I saw that there was already the same for maas-cluster-controller
[09:32] <jtv> caribou: first let's see if allenap knows more.  We may also want to add it to one of the lists in required-packages (in the main source branch) to facilitate development.
[09:33] <caribou> jtv: ok, fine. as long as it is referenced somewhere. I just stumbled over it while testing the other bug
[09:33] <jtv> allenap: do you know more about maas-region-controller needing python-pexpect installed?  Seems to be a missing or misplaced dependency.
[09:36] <jtv> caribou: weird, now I don't see your MP at all...
[09:36] <caribou> jtv: lemme check; I'm far from being a pro @bzr
[09:38] <caribou> jtv: http://goo.gl/qvxu1g
[09:38] <jtv> caribou: it's got a conflict, too.  :(
[09:39] <jtv> Grrr.  That resubmit did not work out the way I hoped.  :(
[09:39] <jtv> I'm sorry about that.
[09:39] <caribou> jtv: nevermind, it's only a few minutes to destroy it & redo
[09:40] <caribou> jtv: let me do it the proper way
[09:40] <jtv> Thanks.
[09:48] <allenap> jtv: I suspect that’s for virsh support via SSH. blake_r?
[09:48] <jtv> blake_r: do you know about the maas-region-controller package seemingly missing a dependency on python-pexpect?
[09:49] <allenap> gmb: Up for a review? https://code.launchpad.net/~allenap/maas/rpc-better-client-error/+merge/234077
[09:50] <gmb> allenap: Sure
[09:51] <gmb> allenap: Lovely. Thankee :)
[09:52] <caribou> jtv: it's there I think : https://code.launchpad.net/~louis-bouchard/maas/lp1346703_rsyslog_ownership/+merge/234080
[09:52] <jtv> caribou: I will have to leave very soon...  still not seeing it on the list for some reason!
[09:52]  * jtv checks again
[09:53] <jtv> Oh yes, there it is.
[09:53] <caribou> jtv: no worry, it can wait until tomorrow
[09:53] <caribou> jtv: or later
[09:53] <jtv> Why does everybody have names of such similar lengths?  :)
[09:53] <jtv> Thanks.
[09:54] <gmb> allenap: In turn, here's my AddVirsh branch. https://code.launchpad.net/~gmb/maas/port-add-virsh-to-rpc/+merge/234082
[09:55] <gmb> (If you've time)
[09:55] <jtv> caribou: I set a commit message (otherwise tarmac won't land the branch, but not complain either).  One thing still looks off: why did the top of the changelog get sliced off?
[09:56] <caribou> jtv: fine; Re: changelog I don't know
[09:56] <jtv> bigjools: drat, I need all of a node's IP/MAC mappings, but StaticIPAddress doesn't directly refer to the MAC.  We don't have anything ready-made for that, do we?
[09:57] <jtv> caribou: have a look at the diff on the MP... a big red section there.
[09:57] <caribou> jtv: oh, crap my fault; lemme fix it
[09:57] <jtv> :)
[09:59] <caribou> jtv: should I just uncommit & fix it or do a new commit ? (told you I was bad at bzr)
[10:00] <jtv> caribou: uncommit is fine, but when you push it back up, the revision will still be on the server.  To get around that, push with the --overwrite option.
[10:00] <caribou> jtv: k
[10:00]  * jtv runs
[10:00] <jtv> nn folks!
[10:00] <rvba> nn jtv
[10:07] <caribou> ok, MP is fixed, jtv can have a look at it tomorrow
[10:52] <gmb> allenap (and maybe rvba; this is part-Django): I have a problem with lp:~gmb/maas/create-node-to-use-RPC. jtv was right about the source of the isolation problem, but now I can't get one of my tests to work… bin/test.maas src/maasserver/rpc/tests/test_nodes.py:TestCreateNode.test_creates_node always produces the following: http://paste.ubuntu.com/8308294/. I've used set_trace() to check that MACAddresses are actually getting created for the node — th
[10:53] <gmb> rvba, allenap: Diff here, for reference: http://paste.ubuntu.com/8308308/
[11:01] <allenap> gmb: I’ll take a look.
[11:10] <gmb> allenap: Thanks.
[11:13] <gmb> allenap: Also, thanks for the review; I thought I'd pushed a version of that branch without the "spoons" logger, which was for debugging purposes :)
[11:14] <allenap> gmb: I like it though. Let’s see if we can introduce it via acronym/bacronym.
[11:16] <gmb> :)
[11:17] <gmb> Synchronous-Procedural-Object-Oriented-Networking
[11:50] <allenap> gmb: That was a tricky one. I’m surprised we haven’t seen it before. http://paste.ubuntu.com/8308719/ fixes it.
[11:50] <allenap> gmb: I’ll write a test for that.
[11:59] <allenap> gmb: I’ll put it up for review.
[12:09] <allenap> gmb: https://code.launchpad.net/~allenap/maas/transactional-close-connections-on-outermost-exit-only/+merge/234092
[12:09]  * allenap goes for lunch
[12:43] <gmb> allenap: Many thanks!
[13:28] <blake_r> jtv: that dependency should be on python-provisioningserver not on maas-region-controller
[13:52] <caribou> allenap: I'm find with your suggestion, I'll fix the branch & push it back
[13:53] <allenap> caribou: Cool, thanks.
[13:54] <caribou> allenap: out of curiosity, what's wrong with -exec on the find cmd ? it forks one proc for each one it finds ?
[13:57] <roaksoax> jamespage: what dependency is this?
[14:08] <caribou> allenap: Done, just pushed the requested change
[14:11] <jamespage> roaksoax, ?
[14:24] <roaksoax> jamespage: sorry :) wrong nick!
[14:26] <jamespage> roaksoax, np
[14:29] <allenap> caribou: Ta!
[14:30] <caribou> allenap: thanks
[14:53] <rvba> allenap: is the cluster supposed to be connected in a dev environment?  I mean, does a dev environment mimics what's happening in a package w.r.t. cluster<->region connection?
[15:06] <allenap> rvba: It should be, yes.
[15:07] <rvba> allenap: hum, it doesn't seem to work (my code works fine from a package, I see the result of my method change when I start and stop pserv).  I'll investigate.
[15:07] <allenap> rvba: If it’s not working, bigjools filed bug 1361037 which might be relevant.
[15:08] <rvba> Ah, that might be it…
[15:13] <roaksoax> caribou: have you ever seen find being used in postinst scripts?
[15:13] <roaksoax> caribou: i'm not comfortable on applying that fix
[15:13] <roaksoax> to packaging
[15:16] <roaksoax> caribou: nevermind, found packaging that uses it
[16:04] <gmb> Branch up for review, for them as has time: https://code.launchpad.net/~gmb/maas/port-add-seamicro-to-RPC/+merge/234148
[16:35] <gmb> allenap: Any idea why http://paste.ubuntu.com/8310773/ would produce http://paste.ubuntu.com/8310796/?
[16:35] <gmb> It succeeds… whilst talkign about a failure.
[16:36] <gmb> Which is suboptimal
[16:36] <allenap> gmb: /me looks
[16:37] <gmb> allenap: I'm guessing that I'm just missing something twistedy
[16:39] <allenap> gmb: Can you run with -v to see which test that’s being emitted from?
[16:42] <gmb> ure
[16:42] <gmb> sure
[16:44] <gmb> allenap: Oh, durr! found the problem. I had find_ip_via_arp() returning None in another test.
[16:44] <gmb> allenap: Thanks for the hint :)
[16:49] <allenap> gmb: Cool :)
[16:50] <roadmr> hello maas folks :) I have a custom image I'd like to deploy using maas (it's a tar.gz that should be "curtin-ready"). How do I make maas aware of it so I can have a node installed with it?
[16:54] <caribou> roaksoax: I had concerns about using find as well
[16:55] <allenap> gmb: Easy karma? https://code.launchpad.net/~allenap/maas/pserv-dhcp-removals/+merge/234153
[16:59] <gmb> allenap: Karma acheived.
[16:59]  * gmb -> out for the evening. Night folks; see you on the morrow.
[17:00] <allenap> gmb: Thanks, have a good evening.
[17:07] <allenap> blake_r: You landed something today (I probably reviewed it even…) re. boot images, iirc. How close are we to not needing the report_boot_images Celery task any more?
[18:14] <roaksoax> caribou: yeah, so provided that there's similar stuff in other packages, I'm happy to keep it
[18:14] <roaksoax> blake_r: ^^
[18:14] <roaksoax> blake_r: to allenap's query?
[19:20] <blake_r> allenap: almost there for not needing the celery task, all the api calls, and the boot image table completely
[19:21] <blake_r> allenap: i will remove them once its ready
[19:29] <lamont> ERROR 2014-09-10 19:28:05,325 maasserver ################################ Exception: 'Expired timestamp: given 1410376478 and now 1410377285 has a greater difference than threshold 300' ################################
[19:29] <lamont> what usually causes that?
[19:31] <blake_r> lamont: the time on the node is 5minutes different than the server
[19:33] <lamont> freshly provisioning node..  I would expect it to run ntpdate, no?
[19:33] <roaksoax> lamont: cloud-init might have a race.. cloud-init is the one who takes care of ensure the clocks are the same
[19:34] <blake_r> roaksoax: https://code.launchpad.net/~blake-rouse/maas/fix-cluster-image-syncing/+merge/234192
[19:34] <blake_r> roaksoax: fixed ^
[19:35] <lamont> ta
[19:38] <roaksoax> blake_r: awesome! does that fix the eveyr 15 min import?
[19:38] <blake_r> roaksoax: yep
[19:38] <roaksoax> blake_r: ok great! so multipart is also done?
[19:38] <blake_r> roaksoax: yep, both up for review
[19:39] <roaksoax> blake_r: awesome! then the only thing left is psycopg?
[19:40] <roaksoax> blake_r: has upstream said anything else?
[19:40] <blake_r> roaksoax: yes
[19:40] <blake_r> roaksoax: needs to be fixed, for if the client is 9.3 but the server is 9.2
[19:40] <blake_r> roaksoax: needs to be fixed, for if the client is 9.3 but the server is <9.2
[19:40] <roaksoax> blake_r: ok, so, that would be the last blocker to support large images then
[19:41] <blake_r> roaksoax: yes
[19:41] <roaksoax> blake_r: anychance you can take care of that today ?
[19:41] <blake_r> roaksoax: hopefully
[19:44] <roaksoax> blake_r: awesome! thanks for the hard work
[19:44] <roaksoax> this is awesome
[19:44] <blake_r> roaksoax: np