[11:23] hello frankban -- welcome back [11:42] morning bac, thank you, how is it going? [11:43] frankban: good, thanks. [11:43] frankban: hey, i have a review mentor for you! [11:43] bac: cool, who is? [11:43] raphaël (rvba) has volunteered but he cannot start for a couple of weeks until the 12.04 release of MAAS [11:44] hope that's ok. he's in france so the time zone should be perfect [11:45] it's perfect, I know him, it was my roommate in budapest, thanks bac [11:45] oh, i did not know that. glad it worked out. [11:46] frankban: perhaps you can coordinate with rvba to see about getting started. you should probably just pick whichever day is his on-call review day and dedicate that day of the week to working with him. [11:46] although now it does not seem reviewing takes nearly as much time as it used to [11:52] cool bac, I will contact him. so the task here is start reviewing code with him until I will be ready to do that by myself? [11:54] frankban: he will explain the reviewing process and approach to you. then, on whatever day he is on call, you'll work with him doing reviews. you'll do a full review but he will then review your review. that step must be taken before the developer can treat the MP as approved. [11:54] as a mentor your reviews are provisional until he approves it. [11:56] in LP we denote that by putting a '*' on the review type to indicate it must be mentored. so when you do a code review you'll mark the review type as 'code*'. later rvba will look at it, and if he agrees, he'll mark it as a 'code' review and then it can be accepted. [11:56] hope that makes sense. it really is quite straightforward [11:57] sure bac, thanks [11:58] frankban: thanks for volunteering to take this step. it really is important for the team and for your development as you get to see all parts of the code base. [11:59] welcome back frankban! I hope you had a great vacation [12:00] morning gary_poster, thanks, yes, I enjoyed my holidays, an the final dissertation of my girlfriend went very well [12:09] frankban: what was her topic? something related to art history, no? [12:10] gary_poster: T-0? [12:10] frankban, exellent! congratulations to her [12:10] frankban, just approved one of your lpsetup (urandom) MPs with comment [12:10] bac, yes oops [12:10] bac benji frankban call ASAP, no later than 2 from now [12:10] bac, architectural designing [12:11] ah, right. [13:16] bac, I'm < 10 min away fwiw. then you'll only have a half hour, but so be it [13:17] ok [13:17] let's try the new super ssh screen sharing https://dev.launchpad.net/yellow/RemoteTerminalBroadcasting [13:24] bac, cool. you're driving, I assume? [13:26] bac, I'm in goldenhorde [13:28] hi gary_poster. joining now [13:29] cool [13:45] bac, fwiw I disconnected from the screen sharing [13:46] gary_poster: just killed it [13:47] cool [13:57] juju has now deprecated default-image-id and default-instance-type. [13:59] ah right [13:59] in favor of constraints [13:59] which I haven't learned how to use yet [14:00] benji, would collaborating be useful? [14:03] gary_poster: sure; let me prepeare [14:04] cool [14:07] gary_poster: the horde awaits [15:25] gary_poster: the new --constraints interface to juju looks like it will make the script easier. no need to rewrite the environments.yaml [15:25] the documentation has problems, though, but it seems to be easy to work around [15:25] awesome bac. and then I can look at your script to see how the heck it actually works now :-) [15:26] gary_poster: work-in-progress: http://pastebin.ubuntu.com/923449/ [15:26] it looks like you can only pass one k=v pair per --constraints param, despite what the docs say [15:27] and you must get rid of default-instance-type and default-image-id from your environments.yaml [15:28] i'm unsure of the relation between instance-type and cpu settings. does a c1.xlarge imply cpu=8? [15:29] bac, the relation is defined by the instance type [15:29] IOW, a given instance type has a certain number of cores [15:30] as defined by Amazon [15:30] bac, look for "virtual cores" in http://aws.amazon.com/ec2/instance-types/ [15:31] gary_poster: so is that the default number of cpus but the --constraint "cpus=n" changes it? [15:32] as seen here: https://juju.ubuntu.com/DeprecatedEnvironmentSettings [15:34] gary_poster: nm [15:34] Note that cpu and mem conflict with instance-type, and should not be specified at the same time; and that setting a service constraint that conflicts with an environment constraint will cause the environment constraint to be ignored for that service. [15:34] bac, ah! ok cool [17:16] * bac -> late lunch + bike [17:26] benji, I see you working, but trying to talk to hallyn. will join in a bit [17:27] gary_poster: k [17:31] frankban, hey. so, I talked to hallyn [17:32] he hadn't seen what I wrote him earlier today [17:32] he is +1 on lxc-ip but it can't go into precise [17:32] we could install in in our own packages but also contribute it upstream [17:34] cool gary_poster, thanks. [17:34] frankban, he asks us to file a bug and then attach a patch [17:35] I'm happy to do whatever will help, or leave it to you. You doing it means more props for you :-) [17:35] (to Ubuntu, I mean) [17:35] frankban, he also wonders if we can do better than the grep [17:36] like, for instance, querying a dhcp server [17:36] he also said this: [17:36] "note that if we add '-q' to lxc's dnsmasq then we can get the ip addr from syslog but i don't see any way to send just the mapping to a file under /var/run/lxc" [17:36] I'm not clear on how we would use that, but maybe you are, or maybe it would give you an interesting thing to look into [17:38] gary_poster: hmm... I have no idea about that right now, but I think it is worth investigating. Didn't know we can avoid using dhcp leases [17:41] me either :P [17:41] I'm not sure we can [17:42] I don't think he is saying "do it this way" but "consider/investigate this way" [17:42] could be wrong :-) [17:48] got it, I think it's worth trying. I will file a bug for adding lxc-ip, EOD, thanks and good evening gary_poster [17:48] thanks frankban, have a nice evening [18:06] benji, I'm in goldenhorde [18:22] gary_poster: am I here? === garyposter is now known as gary_poster [19:00] benji, gary_poster: have you seen this before? http://paste.ubuntu.com/923796/ [19:01] it seems transient, so i'm wondering if we should put a retry option into the 'run' helper command [19:01] bac: not that I remember, looks nasty [19:02] bac, I don't think so either [19:02] it is killing the script b/c it catches this one exception and then gives up [19:14] gary_poster: my machine died hard; doing updates and rebooting and then I'll re-join the horde [19:14] ack benji [19:14] TestProtocolClient is what I was thinking of [19:15] gary_poster: what does that do? [19:15] benji, The ``subunit.TestProtocolClient`` class is a ``unittest.TestResult`` [19:15] extension which will translate a test run into a Subunit stream. [19:18] benji, and the "tags" method behaves exactly as I suspected: [19:18] it has no concept of state [19:18] if you say there is a tag added, [19:19] it reports that the tag is added [19:19] with no concept of whether you are in a test or not in a test, or whether that tag has been reported recently or not [19:19] so if you use that as your test result [19:20] and then you wrap it with something that *does* keep track of state, such as the aggregating thing [19:20] then everything should work out fine [19:20] So, if the logging test result in testtools has no state [19:21] then it would be the closest analog [19:21] and our test should should show that the logging test result correctly is called with the proper add tags or remove tags [19:22] *with the subunit semantics* [19:22] so the real remaining question in my mind is this: [19:22] gary_poster: so... that means that we should be able to strip out the stateful behavior in ThreadedForwardingResult and our WorkerTestResult and all should be happy [19:24] benji, no, because they are responsible for maintaining the subunit behavior, in the current setup. The only problem, and the question to which I alluded, is this: if these things implement subunit policy, why are they in testtools? [19:24] and they really should implement subunit policy for our use. I'm pretty sure, though I'll want to try and convine you verbally when you are back together again to make sure I'm right [19:24] good point, moving them might be the thing to do; have you checked to see if they're used elsewhere in testtools? [19:24] no, will look [19:25] gary_poster: also there's the point that someone other than subunit might be using them and we'll be yanking them out from under them [19:25] yeah, benji. doubtful IMO, but the concern is reasonable and proper. [19:26] * benji watches his laptop install 465 updated packages. [19:28] benji, ConcurrentTestSuite is the only thing that refers to ThreadsafeForwardingResult [19:28] in testtools [19:28] and probably anywhere :-) [19:29] I suspect that this is what will shake out: [19:29] cool [19:29] - jml will tell us that he didn't initially have the idea of per-test tags [19:29] - jml will say that Robert added the idea [19:30] - jml will tell us that he wants to push that idea throughout testtools but hasn't gotten around to it [19:30] - we will be encouraged to add our new bits and bobs to testtools [19:31] - we will also be encouraged to fix up TestResults' tags, if we are up for it [19:31] For the short term, I think we can continue working in testtools [19:31] We should not touch the base TestResults [19:31] we should change the tests we've been writing to look at logs about the tags [19:32] We can then make an MP and raise the questions we have [19:32] gary_poster: I think that'll work. I'm going to reboot and rejoin the horde and we can commence on the above. [19:32] cool [19:38] * gary_poster back in a sec [19:46] gary_poster: I can hear you, but it looks like my virtual self fell asleep [19:47] benji___, :-) now you are no longer in room [19:52] I think I'm back. [19:55] benji, I see you here but not in hangout. talking to lifeless in -ops [19:55] benji, -dev :-) [20:10] gary_poster: I'm going to do the simpler thing. [20:11] benji, cool. +1 [20:32] gary_poster: i just had a quick chat with sean r., the python-memcached bug supervisor. he said he's put the review on his 'short list' but is very busy. i think tomorrow morning i'll prepare the fork. [20:51] man, the juju-ers need to use pyflakes. it's a mess out there [20:51] heh [20:51] and it would've highlighted the error i just had to chase down [20:52] bac, python-memcached: glad he is looking at it, but yes, good, +1 on fork. We can add a card to "tracking" for this after we have the fork landed. [20:52] gary_poster: yep [20:53] the go version of juju has linting built in [20:54] well, go has linting built in I mean [20:54] but I will miss being able to hack it and stick pdbs in it [20:55] even in the production instance [21:00] yeah, I will definately miss pdb when working in a non-Python language