[00:37] <wgrant> wallyworld: It looks like you can use PyCharm's buildout support now, instead of specifying the eggs manually.
[00:38] <wallyworld> wgrant: yes, i hadn't gotten around to looking at that yet :-(
[00:38] <wallyworld> maybe i should make the time
[00:38] <poolie> i'm getting a timeout setting bug status, https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-2043DR6
[00:39] <wgrant> wallyworld: I had to use bin/i18nextract. Only bin/i18n* seem to have the necessary paths.
[00:39] <wgrant> wallyworld: But I added that and removed all the eggs from the sources config, and it seems to work.
[00:39] <wallyworld> excellent!
[00:39] <wgrant> And, indeed, under "External Libraries" there is now "Buildout Eggs"
[00:40] <poolie> wallyworld: which jvm do you use for pycharm?
[00:40] <wallyworld> wgrant: one extra thing - if you want pycharm to know about what's inside bin/run, bin/test etc, open those once initally and tel pycharm they are python files. pycharm relie son file extensions and thouse don't have any :-(
[00:40] <wallyworld> poolie: i use sun's jdk
[00:40] <poolie> is that packaged in ubuntu?
[00:41] <wallyworld> yes, can't recall whether main or ....
[00:42] <wgrant> It's in partner.
[00:42] <wallyworld> makes sense
[00:42] <poolie> ok, got it
[01:04] <StevenK> wgrant: Do you think it's safe to remove bazaar-experts now?
[01:08] <poolie> urh jb seems to have a lot of trouble with unity on my machine
[01:09] <lifeless> jim bean ?
[01:24] <lifeless> wgrant: -haaaaaaaaaaaaa- pids within lxcs are not unique across lxcs.
[01:52] <wgrant> lifeless: Nope.
[01:52] <wgrant> StevenK: Probably, yes.
[01:53] <StevenK> lifeless: Can haz bazaar-experts killed?
[01:53] <lifeless> wgrant: how does our test config isolation work .. :P
[01:58] <wgrant> I wasn't sharing a working directory.
[01:58] <wgrant> But I guess if you do then that's a problem :/
[01:58] <lifeless> wgrant: you made one per parallel thread ?
[01:59] <wgrant> lifeless: The LP tree lived in the base container.
[01:59] <wgrant> It was not bind-mounted it.
[01:59] <lifeless> ah
[01:59] <wgrant> s/it/in/
[02:02] <lifeless> anyhow, memcached sorted.
[02:03] <lifeless> the rabbit layer took a -long- time to dies
[02:03] <lifeless> but no longer hanging
[02:14] <lifeless> still seeing the odd
[02:14] <lifeless> could not get IP address - aborting.
[02:14] <lifeless> with containers taking too long to startup :(
[02:15] <lifeless> and
[02:15] <lifeless> No handlers could be found for logger "lazr.smtptest"
[02:15] <StevenK> That one you see on buildbot and ed2 too
[02:15] <StevenK> *ec2
[02:16] <lifeless> at least now the layers are all starting, seem to be getting clean subunit
[02:17] <lifeless> FAIL: canonical.testing.ftests.test_layers.ZopelessTestCase.testMemcachedWorking
[02:17] <lifeless> Difference: True != False: memcached is live but should not be.
[02:17] <lifeless> TransportError: Transport error: [Errno 1] Operation not permitted: '/var/tmp/bazaar.launchpad.dev/mirrors' [Errno 1] Operation not permitted: '/var/tmp/bazaar.launchpad.dev/mirrors'
[02:21] <sixstring> Anyone know where the source for login.launchpad.net is located? I'm looking for the Django project. (And that's not what launchpad itself is...Zope!)
[02:21] <wgrant> sixstring: lp:canonical-identity-provider
[02:21] <lifeless> lp:canonical-identity-provider
[02:21] <sixstring> Thanks!
[02:21]  * sixstring tosses some donuts toward wgrant and lifeless.
[02:24] <lifeless> ok, that seems good now
[02:24] <lifeless> id=3, tests=2089, failures=5, skips=80
[02:24] <wgrant> lifeless: Nothing hung?
[02:24] <lifeless> wgrant: indeed
[02:24] <wgrant> Full test suite run now.
[02:24] <wgrant> Now!
[02:25] <lifeless> wgrant: patience kemosabe
[02:25] <StevenK> lifeless: Do you need changes to hit devel before we turn parallel-test back on?
[02:25] <lifeless> I'm comparing single threaded on laptop with 8 threads on desktop
[02:25] <lifeless> StevenK: no, but I need you to upgrade jenkins to oneiric and setup lxc.
[02:26] <StevenK> ... I can see that happening with buildbot :-P
[02:31] <lifeless> hmmm, I wonder if I have the timing fixed branch of testtools here, I seem to be load balancing the tests poorly.
[02:32] <lifeless> or maybe there is some gargantuan test matching the regex 'canonical'
[02:32] <lifeless> 7/8 workers completed a while back
[02:32] <lifeless> or maybe they are running too many tests, but the load-list stuff was fairly robust I thought
[02:33] <wgrant> There is a test that hangs on 2.7 matching 'canonical', but I guess your containers are lucid and 2.6?
[02:33] <lifeless> right
[02:33] <lifeless> its busy in CPU
[02:44] <LPCIBot> Project db-devel build #784: FAILURE in 5 hr 45 min: https://lpci.wedontsleep.org/job/db-devel/784/
[03:04] <wgrant> wallyworld: Did you have to configure a custom cwd somewhere to get bin/run debuggable>
[03:05] <wallyworld> wgrant: you set the wd in the debug config
[03:05] <wallyworld> plus you need a custom PYTHONPATH variable: parts/scripts:lib:$PYTHONPATH
[03:06] <wallyworld> set this in the same config dialog
[03:06] <wgrant> Where's the debug config?
[03:06] <wgrant> The last IDE I used seriously was VS2003, so I'm a little rusty on how things work these days.
[03:06] <wallyworld> there's a drop down next to the run/debug icons in the top toolbar
[03:07] <wallyworld> you need to initially set up a debug profile
[03:07] <wallyworld> for lp. i alsi have one for runnign tests
[03:07] <wgrant> Ahh, thanks.
[03:07] <wallyworld> the script is bin/test
[03:07] <wallyworld> the params are -vvct foo
[03:07] <wallyworld> for running, the script is bin/run
[03:08] <wallyworld> the params are -r librarian,google-webservice,memcached -i development
[03:11] <wgrant> lifeless: You has qa.
[03:12] <lifeless> hah
[03:12] <lifeless> parallel - 15 minutes
[03:12] <lifeless> single threaded 13 minutes
[03:13] <lifeless> Total: 1338 tests, 0 failures, 0 errors in 12 minutes 38.127 seconds.
[03:13] <lifeless> id=4, tests=1686, failures=2, skips=29
[03:13] <wgrant> Heh.
[03:13] <lifeless> the extra tests are layers - different reporting
[03:13] <spm> parallel is slower? that sounds like doing it wrong. :-)
[03:14] <lifeless> yes
[03:14] <lifeless> this is why 'in dev' not 'done'.
[03:14] <spm> pfft. details. and facts. they have no place here.
[03:38] <lifeless> aka 'dont bother me with facts'
[03:43] <wgrant> lifeless: Last staging fastdowntime was offline for 91s.
[03:43] <wgrant> Looks like my optimisations last night were effective.
[03:43] <lifeless> getting there
[03:43] <lifeless> wgrant: thanks for digging in!
[03:43] <lifeless> thats still running trusted.sql ?
[03:43] <wgrant> Will hopefully dig harder to reduce sync overhead tonight.
[03:43] <wgrant> Yes.
[03:43] <lifeless> be good once we eliminate that
[03:44] <wgrant> Overhead for running that too is now like 2s.
[03:44] <wgrant> So not that bad.
[03:44] <lifeless> I have to pop out and buy a baby capsulte
[03:44] <wgrant> Uhoh.
[03:44] <lifeless> wgrant: thats still 2.5% :P
[03:44] <lifeless> wgrant: I will poke at qa upon my return
[03:44] <wgrant> Hmm, we reset permissions serially :(
[03:44] <lifeless> wgrant: but it all should be super shallow
[03:44] <wgrant> That will save 30s on production, but only 5s on staging.
[03:44] <wgrant> lifeless: Thanks. We're OK to deploy otherwise.
[03:52] <StevenK> lifeless: Attempting to create an Oneiric EMI
[04:55] <lifeless> StevenK: cool
[04:57]  * wgrant curses postgres a bit.
[04:58] <lifeless> oh?
[04:58] <wgrant> Tried to parallelise security.py
[04:59] <wgrant> But postgres does *not* like concurrent group modifications.
[04:59] <lifeless> will block
[04:59] <wgrant> Nope.
[04:59] <wgrant> Get lovely "tuple concurrently updated" exceptions.
[04:59] <lifeless> WIN
[04:59] <lifeless> WIN WIN WIN WIN WIN
[05:00] <wgrant> Yes.
[05:00] <wgrant> So I try to guess the hosts from the connstrings, and run a separate set of threads first to reset the roles once per host.
[05:00] <wgrant> Seems to work.
[05:00] <wgrant> But ew.
[05:02] <wgrant> I wonder if it gets faster if I share the PermissionGatherers.
[05:02] <wgrant> Overhead is down from 6s per slave to 0.5s, but that's still pretty bad...
[05:09] <lifeless> what is per slave?
[05:10] <wgrant> Hm?
[05:10] <wgrant> Permissions aren't replicable, so must be set separately on each slave.
[05:10] <lifeless> can't we do them concurrently on each slave?
[05:10] <wgrant> This presently takes 6s per slave, serially.
[05:10] <wgrant> Yes.
[05:11] <wgrant> But you can't just run multiple instances of the script.
[05:11] <wgrant> 1) slow startup
[05:11] <wgrant> 2) if there are multiple DBs on one machine (eg. prod standalone + slave, or staging, or dev), ALTER ROLE boom.
[05:11] <lifeless> erm
[05:11] <lifeless> do you mean multiple DBs on one pgsql instance ?
[05:11] <wgrant> Yes.
[05:12] <lifeless> we could move them to separate clusters, same machine.
[05:12] <wgrant> Ew.
[05:19] <jtv> wgrant: since you're working with the PermissionGatherers, a note of caution that I may or may not have preserved as a comment: I tried more aggressive bundling and found that performance got worse, not better.
[05:25] <jtv> Also, I really wonder whether all the restrictions we put in security.cfg pull their weight.  Say we isolated a few tables that need special SELECT permission, and went back to granting blanket SELECT permissions to the rest.  Less need for detailed testing, fewer pointless privilege errors, but more relevantly for this: fewer security.cfg changes.
[05:26] <wgrant> Julian has argued similarly.
[05:27] <wgrant> It's unfortunate that there's no way to really batch permission changes, without poking pg_class.relacl directly.
[05:27] <wgrant> Which may not be entirely unreasonable...
[05:27] <StevenK> Just disgusting
[05:27] <wgrant> Apparently very disgusting.
[05:28] <StevenK> So disgusting, jtv left in disgust.
[05:28] <wgrant> Yes.
[05:28]  * StevenK *might* have a working Oneiric EMI
[05:32] <StevenK> Well, I'll be able to actually check if the instance state ever moves from pending
[05:33] <StevenK> Bah, my branch failed with test_feature_info failing
[05:41] <nigelb> oh oh
[05:41] <nigelb> someone broke something?
[05:41] <nigelb> Reported by Matthew Paul Thomas (mpt: 5235) [ubuntu-bugcontrol] on 2005-11-18 and last updated on ": {"date_
[05:42] <nigelb> the last updated doesn't seem to be working :)
[05:43] <wgrant> nigelb: That looks like a Greasemonkey script.
[05:44] <wgrant> We don't show team memberships, karma, last updated.
[05:44] <wgrant> And we only show usernames to a few people.
[05:45] <nigelb> wgrant: Oh, that. It started working recently. I'll check with Brian :)
[05:45]  * wgrant fixes the db-devel breakage.
[05:46] <wgrant> jtv: So, I wonder if we might be better off querying pg_class.relacl, working out what permissions are currently there, and then applying only the diff.
[05:47] <wgrant> jtv: Rather than revoking and granting *everything*.
[05:47] <jtv> I thought someone had already implemented incremental changes.
[05:47] <wgrant> jtv: There's --no-revoke
[05:48] <wgrant> Which, as the name suggests, doesn't revoke. Or change owners.
[05:54] <jtv> It doesn't revoke?  Or it doesn't do the blanket revoke at the beginning?
[05:54] <jtv> ISTM if you skip the blanket revoke at the beginning, that breaks privilege revocation.
[05:56] <wgrant> jtv: Right, it breaks revocation.
[05:56] <wgrant> We run --no-revoke for nodowntime deploys.
[05:56] <wgrant> And do the revoke only during (fast)downtime.
[05:56] <jtv> And that's the problem you're trying to solve right now?
[05:57] <wgrant> jtv: Currently a full security.py run takes 6 seconds per DB.
[05:57] <wgrant> jtv: And these are run serially.
[05:58] <wgrant> Production has 7 DBs.
[05:58] <wgrant> Which means we are going to spending 42 seconds of downtime just resetting permissions.
[05:58] <wgrant> Which is less than ideal.
[05:58] <jtv> That reminds me of something else.
[05:59] <wgrant> Hmmm.
[05:59] <wgrant> autovacuum causes fastdowntime to abort, it seems...
[05:59] <jtv> ISTR the performance increase I got from bundling the grants (not related, I'm sure) shifted the performance bottleneck to somewhere else, even within security.py.  That was just for one database though.
[07:25] <wgrant> lifeless: :(
[07:26] <lifeless> wgrant: ?
[07:26] <lifeless> wgrant: My mind reading is pretty good, but not enough to get much from that :)
[07:27] <wgrant> Profiling slony.
[07:27] <wgrant> It is slow.
[07:27] <wgrant> ddlScript_complete_int, in particular.
[07:27] <wgrant> Which turns replication back on.
[07:27] <wgrant> Looks like LOCK TABLE blah IN ACCESS EXCLUSIVE MODE takes about 50ms.
[07:28] <wgrant> So not really slony.
[07:28] <wgrant> More postgres.
[07:28] <lifeless> stub is aiming to get u1 onto slony 2
[07:28] <wgrant> (it does that for every table)
[07:28] <lifeless> then upgrade us
[07:28] <wgrant> I wonder if it's any better.
[07:28] <lifeless> slony 2 does not do that
[07:29] <wgrant> slony1-2
[07:30] <wgrant> Nice package name.
[07:32] <wgrant> Huh, it renames the relations?
[07:32] <wgrant> updateRelname confuses me.
[07:34] <wgrant> Locking takes 45ms, checking for trigger conflicts 5ms... 50ms*250 = 12.5s :/
[07:39] <wallyworld> lifeless: in lib/canonical/configure.zcml, there's an include package="lazr.uri" but there's no configure.zcml in /usr/lib/python2.6/dist-packages/lazr/uri and so it complains. is it mandatory to have a configure.zcml file for such includes?
[07:40] <lifeless> I suspect skew over time
[07:40] <lifeless> rem
[07:41] <wallyworld> you mean delete the include?
[07:41] <lifeless> no
[07:41] <lifeless> the package is faulty
[07:41] <lifeless> we use the egg
[07:41] <lifeless> ls -l eggs/lazr.uri-1.0.2-py2.6.egg/lazr/uri/configure.zcml
[07:41] <wallyworld> ah right. thanks. will remove the package
[07:41] <wgrant> wallyworld: I struck that today in pycharm, then it magically started working again.
[07:42] <wallyworld> wgrant: yes, it only started happening once i used buildout
[07:42] <wallyworld> wgrant: you like pycharm?
[07:42] <wgrant> Mmm.
[07:42] <wgrant> Ugly and slow.
[07:42] <wgrant> But maybe.
[07:43] <wallyworld> slow? really? ugly is a matter of opinion. there's several different themes to choose from
[07:43] <wgrant> I can't get it to render fonts nicely.
[07:43] <wallyworld> i use Alloy Bedoin
[07:44] <wallyworld> and override default fonts by Verdana
[07:44] <wallyworld> in the Appearance settings
[07:44] <lifeless> wallyworld: if its competing with vim for perceived performance, it is really quite challenging :)
[07:45] <wallyworld> there's more to performance than startup time or whatever. things like code navigation, change markers erc rock and save sooo much time
[07:45] <wgrant> They do.
[07:46] <wgrant> But I'm used to my editor not having visible latency.
[07:46] <wgrant> Even PyCharm's menus lag.
[07:46] <wallyworld> it doesn't for me
[07:46] <wallyworld> there must be something else happening
[07:46] <wallyworld> on your system
[07:46] <wgrant> Hmm
[07:46] <wallyworld> i think it's fast for bigjools too
[07:47] <wallyworld> i'd say there's definately an issue somewhere
[07:47] <wallyworld> maybe with java?
[07:47] <wallyworld> you using sun's jdk?
[07:47] <wgrant> I am.
[07:47] <wallyworld> hmmm. there goes that theory
[07:50] <wallyworld> wgrant: one thing to do - make sure your pycharm/bin/pycharm.vmproperties has more max memory specified
[07:50] <wallyworld> -Xms232m
[07:50] <wallyworld> -Xmx912m
[07:50] <wallyworld> -XX:MaxPermSize=120m
[07:50] <wallyworld> -ea
[07:50] <wallyworld> lp project likes to use a lot
[07:51]  * wallyworld has to start getting ready for soccer
[07:57] <wgrant> lifeless: Ahh.
[07:58] <lifeless> wgrant: and again
[07:58] <lifeless> wgrant: CONTEXT
[07:58] <wgrant> lifeless: Slony2 doesn't really disable the triggers... it sets a value which turns them into no-ops.
[07:58] <wgrant> So it should be really quick.
[07:58] <wgrant> That makes a bit more sense.
[08:00] <wgrant> Just to make upgrades fun, slony1 and slony1-2 packages conflict!
[08:00] <lifeless> yes
[08:00] <lifeless> two fastdowntimes
[08:00] <lifeless> or something
[08:01] <wgrant> One to uninstall slony and move everything to the master, then upgrade slony everywhere, then another fastdowntime to install slony2, then rebuild slaves, then get things talking to the slaves again?
[08:02] <lifeless> yeah
[08:03] <mrevell> Morning
[08:24] <wgrant> 2011-08-05 08:23:57 INFO    Outage complete. 0:00:26.220996
[08:25] <wgrant> 15s of that was security.py, which can hopefully be optimised down to less than a second.
[08:25] <wgrant> Morning stub.
[08:26] <stub> Urgh
[08:26] <wgrant> That bad?
[08:26] <stub> My sleep schedule is utterly broken
[08:26] <stub> again!
[08:26] <lifeless> 2:30pm ?
[08:26] <stub> 3:30pm
[08:26] <wgrant> Ow.
[08:29] <nigelb> Fixing that is going to be painful.
[08:30] <jtv> stub: I missed dinner last night… ended up staying at home and, from what it looks like, drinking myself into a hangover from Tesco fruit juice.
[08:30] <jtv> I would recommend it, except it doesn't help us much as I'd hoped.
[08:31] <jtv> Did you get a chance to snuggle in at the trough?
[08:31] <jtv> At John's, I mean.
[08:31] <wgrant> Hmmm.
[08:31] <wgrant> Interesting.
[08:32] <wgrant> If I add new slaves without restarting the existing slons, syncing is really slow.
[08:32] <wgrant> Like, slony1-slow.
[08:32] <wgrant> But when I restart them all, it drops back to 2s.
[08:32] <wgrant> And we have 30s outages again.
[08:32] <wgrant> Oddity.
[08:33] <wgrant> stub: Does that happen with slony 1 too? I've upgraded to 2 to see how less crap it is.
[08:34] <wgrant> stub: With slony 2, sync lag around the upgrade is now the slon interval, rather than >20s.
[08:37] <stub> jtv: If you have a hangover, it might have been past its use by date...
[08:38] <stub> jtv: Yup, and take away. Good stuff.
[08:38] <jtv> stub: possibly… I think I just drank too much.
[08:39] <stub> wgrant: Cool. We have other reasons to switch, and I want to install an Ubuntu One system with slony2 if I can get the packages sorted.
[08:40] <stub> wgrant: You found slony2 packages built somewhere?
[08:40] <stub> I think they are in Debian, but don't think they have leaked through to Ubuntu yet due to no upgrade path between slony1 & 2.
[08:41] <LPCIBot> Project db-devel build #785: STILL FAILING in 5 hr 57 min: https://lpci.wedontsleep.org/job/db-devel/785/
[08:43] <stub> oic - silly version numbers hiding it from me.
[08:44] <stub> Need to get 2.0.7 still - Natty has 2.0.6
[08:45] <stub> wgrant: so did the existing scripts all work unmodified?
[08:50] <wgrant> stub: Sorry, was eating.
[08:50] <wgrant> stub: Yep, everything works fine.
[08:50] <wgrant> Just installed the new package (which conflicts with the old one) and rebuilt the cluster from scratch.
[08:50] <wgrant> No issues with that, new-slave, or full-update.
[08:51] <wgrant> oneiric still has 2.0.6 :(
[08:52] <wgrant> sid too.
[08:52] <wgrant> Sad
[08:52] <stub> 2.0.7 was only recently released.
[08:56] <wgrant> stub: With 4 slaves and a multithreaded security.py, 31s outage.
[08:56] <wgrant> security.py is the main limiting factor now.
[08:56] <wgrant> It's about 15s with 4 slaves, even multithreaded.
[08:57] <stub> wgrant: you still seeing a high variance though when slony is bounced/not bounced before the upgrade?
[08:57] <wgrant> stub: Yes, it adds a good 15-20s.
[08:58] <wgrant> I thought it was just really bad scaling, but then bounced the slons and all was good.
[08:58] <stub> security.py could be optimized further separately. eg. run '--no-revoke' before the outage and add a '--revoke-only' argument for application during the outage.
[08:58] <wgrant> stub: I think it may be better to examine the permissions and owners and just apply a diff.
[08:59] <wgrant> Since presently it revokes everything then grants everything, so --revoke-only isn't really plausible.
[09:00] <wgrant> We already inspect pg_class in a few places... not toooo terrible to also interpret its relacl.
[09:00] <stub> Yer. Haven't poked at that part of the schema - just used GRANT and REVOKE
[09:00] <wgrant> I'd be reluctant to update relacl manually, but using it to work out a diff seems reasonable and quick.
[09:01] <stub> We will still need to do revokations though, which is the potentially blocking operation. Grants can be done outside of the outage.
[09:01] <wgrant> Sure, but if we're only applying a diff it should be really quick.
[09:01] <wgrant> So we can probably do it all in one hit.
[09:01] <stub> We already are really quick. We are just changing the definition of really quick :-)
[09:02] <wgrant> 'SELECT relnamespace, relname, relacl FROM pg_catalog.pg_class;' can't be too slow :)
[09:02] <wgrant> Then it's just a matter of parsing them into something that we can compare to security.cfg and diffing.
[09:02] <bigjools> wgrant: hey you used PyCharms buildout support then?
[09:02] <wgrant> Not a huge amount of code, and should be very quick.
[09:03] <stub> Depends on how many corresponding relacl rows there are, and if all the role membership stuff is exploded or not.
[09:03] <wgrant> bigjools: I did. Possibly slightly unreliable (had some odd import issues), but seems to work.
[09:03] <bigjools> gotta be better than setting all the egg directories
[09:03] <wgrant> Exactly.
[09:03] <wgrant> I used bin/i18nextract for paths.
[09:03] <wgrant> Since only the i18n scripts have them.
[09:04] <wgrant> stub: It's not exploded.
[09:06] <stub> Love my weather indicator. Bangkok is expecting Bacon.
[09:07] <bigjools> !
[09:07] <wgrant> Heh
[09:07] <stub> wtf is 'light rain' horizontal wavy lines?
[09:07] <wgrant> I thought that was fog.
[09:07] <stub> That would be 'light rain is a really, really strong wind'
[09:07] <stub> Not in Bangkok obviously
[09:08] <bigjools> I have my own weather station, it'd be nice if I could make HTC's weather app use it.  But no.
[09:09] <allenap> Anybody fancy doing a review?
[09:09] <bigjools> allenap: you are on holiday, bugger off
[09:10] <allenap> bigjools: Hehe. I'm catching up a big I missed from yesterday :)
[09:10] <stub> I'll have your holiday if you are not using it. Ta!
[09:12] <jtv> cjwatson: got a moment to talk about bug 659769?
[09:12] <_mup_> Bug #659769: should copy custom uploads to newly-initialised release <derivation> <lp-soyuz> <new-release-cycle-process> <soyuz-publish> <Launchpad itself:In Progress by jtv> < https://launchpad.net/bugs/659769 >
[09:12] <nigelb> stub: You're based out of Bangkok now?
[09:12] <stub> yes
[09:13] <nigelb> nice
[09:13] <stub> Come on over, the weather is bacon!
[09:13] <nigelb> heh
[09:13] <nigelb> I'm glad there's someone at timzone between me and .au
[09:13] <stub> I don't know what timezone I'm in. Not Bangkok's, certainly.
[09:14] <stub> Probably in the middle of the Atlantic at the moment.
[09:14] <nigelb> hehe
[09:14] <nigelb> I've figured out that my brain thinks I live in Iceland.
[09:17] <lifeless> stub: nah, you're running on france time more or less
[11:06] <jml> I'm looking at a perl script
[11:06] <jml> The first line is a comment, '# Load everything in a big hash'
[11:07] <jml> *every* perl script does that at the beginning
[11:11] <jelmer> jml: I think the hash at the beginning of that line is probably not big enough to fit everything. :P
[11:12] <jml> jelmer: :D
[11:47] <wgrant> stub: Is the admin role still used?
[11:49] <jelmer> sigh, I hate eggs.
[11:50] <wgrant> stub: (it's the only remaining hole in my diffing security.py, as it's difficult to map the ALL that is granted to admin to real permissions)
[11:51] <stub> wgrant: I don't think the admin role is used
[11:51] <stub> Maybe for testadmin?
[11:51] <wgrant> Argh, yes.
[11:51] <wgrant> I guess I might specialcase it for revocation too.
[11:52] <stub> We could explode the ALL into real permissions by object type
[11:52] <wgrant> But just using a grant/revoke diff takes it from 6s to 1.5s per slave... will look at roles next week.
[11:52] <wgrant> I considered that.
[11:52] <wgrant> But they vary by type and version, so mrrrh.
[11:52] <wgrant> ALL is only used for admin, so I'll just special case it for revokes as well.
[11:52] <stub> We could also just do those grants outside of the outage
[11:52] <stub> We revoke ALL?
[11:53] <wgrant> The current security.py revokes ALL from everyone on everything.
[11:53] <wgrant> Then grants the security.cfg permissions, and gives ALL to admin on any object mentioned in security.cfg.
[11:54] <stub> ic
[11:55] <wgrant> Now I interpret relacl, turn the security.cfg + ALL to admin stuff into a dict, and work out differences. Perhaps I could just assume that admin never gets anything revoked.
[11:55] <wgrant> Ah, but it will also never get anything granted.
[11:55] <wgrant> So I probably do need to work out what's in ALL for each type.
[11:55] <wgrant> Any idea where I would find that?
[11:55] <stub> wgrant: I wonder if 'grant ALL to ADMIN ON foo, bar, baz...' would work fine - one statement.
[11:56] <wgrant> It does.
[11:56] <wgrant> I guess I could just do that.
[11:56] <wgrant> Outside the loop of everything.
[11:56] <wgrant> Just always do that.
[11:56] <stub> Yup
[11:56] <wgrant> That single extra statement can't hurt too much.
[11:56] <stub> Two statements, but big ones :-)
[11:56] <stub> Or not revoke - one statement
[11:57] <wgrant> Well, the thing is that we only revoke from tables and roles that we know about.
[11:57] <wgrant> And admin has ALL on everything that we know about.
[11:57] <stub> So REVOKE seems pointless
[11:57] <wgrant> So there's nothing to revoke, unless tables have been dropped from security.cfg, in which case we don't know of their existence.
[11:58] <wgrant> Right.
[11:58] <wgrant> So I'll just do a mass grant.
[11:58] <stub> yup.
[11:59] <stub> http://onefte.com/2011/06/27/youre-such-an-enabler/
[12:00] <stub> mthaddon: Any progress on firewall rules and pgbouncer on wildcherry?
[12:00] <stub> ECHAN
[12:01] <wgrant> That adds almost 200ms to each node :(
[12:02] <wgrant> Ah, that's better.
[12:05] <wgrant> Looks like I can save a second by iterating over the objects as a set rather than a dict :S
[12:06] <wgrant> Ahem, no, I just failed to add everything to the set.
[12:42] <wgrant> 2011-08-05 12:42:28 INFO    Outage complete. 0:00:20.629842
[12:42] <wgrant> yay.
[13:07] <bigjools> howdy bac
[13:07] <bac> hi there bigjools
[13:07] <bigjools> bac: you reviewing?  I have a wee branch
[13:08] <bac> you wee'd on a branch?
[13:08] <bigjools> frequently.  It's a long trip to the house across the garden
[13:08] <bac> uh, that's what a garden is for
[13:09] <bac> i'll have a look at your branch.
[13:09] <nigelb> eww :P
[13:09] <bigjools> bac: https://code.launchpad.net/~julian-edwards/launchpad/queue-links/+merge/70554
[13:09] <bigjools> thanking you
[13:14] <bac> bigjools: i looked at the link on dogfood but i don't see what you describe.  do i need to do something to trigger it or am i looking at the wrong place?
[13:14] <bigjools> bac: look down at the package called "adapt"
[13:15] <bac> ah, gotcha
[13:25] <bac> bigjools: r=bac with one bikeshed
[13:26] <bigjools> bac: oooo :)
[13:26] <bigjools> bac: heh - in soyuz, we bikeshed you
[13:27] <bigjools> you know about all the acronyms :)
[13:36] <abentley> henninge: bzr alias mpull="pull -v -d :submit"
[13:37] <abentley> henninge: bzr alias spump="pump --from-submit"
[13:42] <sinzui> jcsackett, I have looked at bugs, branches, teams, and P3As. I think bug 298152 is really fixed
[13:42] <_mup_> Bug #298152: privacy portlet is not visible enough for indicating private objects <disclosure> <lp-web> <oem-services> <privacy> <qa-needstesting> <ui> <Launchpad itself:Fix Committed by jcsackett> < https://launchpad.net/bugs/298152 >
[13:45] <jcsackett> sinzui: fantastic. :-P you beat me to all my qa this morning.
[13:46] <sinzui> I found a bug that your work should have fixed, and in deed it did. I kept qaing to be certain
[13:47] <jcsackett> cool.
[13:56] <abentley> bac: Could you please review https://code.launchpad.net/~abentley/launchpad/induce-latency/+merge/70571 ?
[13:59] <danilos> bac, hi, I've got a 20 line diff on https://code.launchpad.net/~danilo/launchpad/bug-810116/+merge/70564 as well, if you can find the time to review it, that'd be great
[14:01] <abentley> bac: Actually, let me resubmit that as a new branch.
[14:06] <abentley> bac: Could you please review https://code.launchpad.net/~abentley/launchpad/induce-latency/+merge/70571 ?
[14:06] <abentley> bac: I mean https://code.launchpad.net/~abentley/launchpad/local-latency-port/+merge/70572 ?
[14:11] <bac> abentley, danilos: queued
[14:11] <abentley> bac: ty
[14:13] <bac> danilos: due to the tininess of your branch and the lateness of your hour i jumped you to the top.  r=bac
[14:15] <abentley> henninge: This is the scripting framework I accidentally wrote: https://code.launchpad.net/~abentley/launchpad/local-latency-port/+merge/70572
[14:15] <danilos> bac, thanks
[14:20] <bac> sinzui: are you familiar with ian's person-picker expander work?
[14:21] <sinzui> I am
[14:22] <sinzui> oh, I reviewed his branch about 30 minutes go
[14:22] <sinzui> bac Sorry. I think I stepped on you
[14:23] <bac> sinzui: so you did.  np.  i couldn't get it to work but i think it is b/c i didn't rebuild js
[14:23] <bac> i would like to see it in action, though
[14:23] <sinzui> bac: you would need to do that
[14:23] <bac> and i am...
[14:23] <bac> :)
[14:27] <henninge> abentley: cool
[14:35] <LPCIBot> Yippie, build fixed!
[14:35] <LPCIBot> Project db-devel build #786: FIXED in 5 hr 53 min: https://lpci.wedontsleep.org/job/db-devel/786/
[14:37] <bac> sinzui: i'm still not able to see the expander in action.  i
[14:37] <bac> i've confirmed i have ian's changes loaded in the launchpad.js that is being used
[14:37] <sinzui> Do you also have the feature flags enabled for the picker's new features
[14:37] <bac> gah!!!
[14:38] <sinzui> bac: you want the disclosure rules on: https://qastaging.launchpad.net/+feature-rules
[14:38] <bac> no mention of FF in the mp and i didn't look at the entire branch
[14:38] <bac> thanks
[14:39] <sinzui> bac: it depends on a lot of other branches. one I QAed just an hour ago
[14:39] <sinzui> We are moving a little too fast. I am taking a break from pickers today
[14:41] <bac> sinzui: now i see it.  thanks!
[14:42] <bac> sinzui: did ian consider using the gallery accordion widget?
[14:43] <sinzui> bac No.but now that you mention it, it might solve the dead left margin created by the expander
[14:43] <bac> abentley: your MP has henninge as a reviewer.  is he working on it?
[14:44] <bac> sinzui: it's already in the tree.  may be overkill, may be a nice solution
[14:44] <abentley> bac:  I just told henninge about it, but maybe he decided to review it.
[14:45] <henninge> abentley, bac: I am reviewing it but got distracted
[14:45] <bac> abentley: ok, it looks like he claimed it then.  i'll not do it unless asked
[14:45] <bac> henninge: ok.  let me know if you need to punt it back
[15:14] <henninge> abentley: wrong channel? ;-)
[15:15] <abentley> henninge: yeah.
[15:15] <henninge> abentley: I believe so, yes. Every text field will be obfuscated.
[15:15] <henninge> which reminds me we still need special fields for revisions
[15:15] <abentley> henninge: I think we should call the type "identifier".
[15:16] <henninge> fbm
[15:16] <henninge> abentley: review done, needs fixing.
[15:40] <cr3> benji: if I have an interface exporting a List(value_type=TextLine()), how can I require that the list not be empty?
[15:41] <benji> cr3: "exporting" meaning over the web service API?
[15:41] <cr3> benji: yep, I meant as part of @operation_parameters
[15:43] <benji> cr3: ah; I am not aware of a way to do that declaratively, you'll need to raise an exception if that precondition is not met
[15:43] <danilos> stub, btw, does not ALTER INDEX RENAME TO not work with primary keys? (for table renames and slony)
[15:45] <cr3> benji: might you happen to know offhand which exception I should raise that would be the same as not providing an argument for other types?
[15:47] <benji> cr3: Python raises a TypeError if not enough arguments are provided, I don't know offhand if lazr.restful does something different before Python gets a chance
[15:48] <cr3> benji: I'll try it out, thanks!
[15:48] <benji> np
[15:48] <abentley> henninge: I've updated the docs and pushed.  I don't understand your implementation suggestion.  Could you explain it?
[15:48] <henninge> abentley: sure
[15:52] <henninge> abentley: I was thinking along the lines of this: http://paste.ubuntu.com/659367/
[15:52] <henninge> abentley: or maybe I got that wrong?
[15:53] <henninge> abentley: I assumed defaults can be specified in this manner.
[15:54] <abentley> henninge: They can be.  Doing it as a separate step is a bit of a relic of a previous state of the code.
[15:55] <henninge> I find it a bit strange that getargspec returns None if no defaults are given.
[15:55] <henninge> It should just return an array of Nones
[15:55] <henninge> nuns?  ;-)
[15:55] <henninge> it's Friday
[16:00] <abentley> henninge: Yeah, me too.  Hate code that treats None and empty container as the same.
[16:00] <abentley> henninge: Anyhow, updated and pushed.  Is that what you meant?
[16:03] <henninge> oh, diffs are agregated
[16:07] <henninge> abentley: I just realized I had missed two revisions
[16:08] <henninge> abentley: I had not seen the type being inferred from the default (13598)
[16:08] <henninge> failed to reload
[16:08] <abentley> henninge: Ah.  I did it while brad was working on the other review.
[16:09] <henninge> abentley: I should have been clearer about reviewing it.
[16:09] <henninge> but since I was looking at it, I thought I might as well review it ...
[16:09] <abentley> henninge: It was a nice thing to do.  Oh well.
[16:11] <henninge> abentley: one more thing that I forgot
[16:11] <henninge> abentley: getattr(function, '_helps', {}) can be cached, too, I believe
[16:11] <henninge> arg_helps
[16:12] <abentley> henninge: sure.  will do.
[16:12] <henninge> abentley: but anyhow, this *is* what I had in mind.
[16:13] <henninge> abentley: what about a test? Or do you think this can do without?
[16:13] <abentley> henninge: We don't usually test our utilities, do we?
[16:13] <henninge> ah, right.
[16:14] <henninge> abentley: yes, I had just arrived at that conclusion, too ... ;-)
[16:14] <henninge> abentley: r=me, thanks for the good work
[16:14] <henninge> actually, I'll wait until you pushed that last change
[16:15] <abentley> henninge: pushed.
[16:24] <henninge> abentley: approved. See you on Monday.
[16:24] <abentley> henninge: ta!
[17:12] <stub> danilos: No. Slony caches the name of the primary key in one of its internal tables and isn't smart enough to notice when it has changed.
[17:13] <stub> danilos: I think they stopped doing that in the 2.0 series, or it could be fixed in 1.2 if anyone could be bothered.
[18:45] <benji> bac: if you would, please add https://code.launchpad.net/~benji/launchpad/bug-590014/+merge/70614 to your review queue; thanks
[18:45] <bac> benji: ok
[18:53] <bac> benji: did you move the template files from being registered views to properties on the existing view necessary to take advantage of the cachedproperties?
[18:54] <benji> bac: partly, also so the view wouldn't be instantiated more than once (duplicating queries the second and third times it was instantiated)
[18:54] <bac> benji: right.  smrt.
[18:54] <bac> benji: do you have any demonstration that it actually worked?
[18:56] <benji> bac: heh, yep; I used the ++profile++ view on a dev instance to track the queries that were actually executed before and after
[18:57] <bac> benji: ok.  it looked like it *should* be helpful
[18:57] <benji> :)
[18:58] <jcsackett> sinzui: did you see that bug 89476 was marked fixed release on lp? is there an associated bit you want to deal with or shall i just delete the card?
[18:58] <_mup_> Bug #89476: busted permissions: cannot unsubscribe ubuntu-security when private <disclosure> <lp-bugs> <Launchpad itself:Fix Released> < https://launchpad.net/bugs/89476 >
[18:59] <sinzui> jcsackett, I see lifeless marked it as fix released
[19:00] <sinzui> He saw my tag I think
[19:00] <jcsackett> dig. i have kanban open, i'll kill the card.
[19:06] <sinzui> jcsackett, mumble?
[19:06] <jcsackett> sinzui: sure, one moment.
[19:28] <abentley> bac: could you please review https://code.launchpad.net/~abentley/launchpad/resubmit-target-prerequisite-same/+merge/70615 ?
[19:29] <bac> abentley: ok
[19:43] <dobey> hmm. i keep getting a 500 error when requesting build of one recipe through the API, at least for our bot user. wonder why :-/
[20:26] <LPCIBot> Project db-devel build #787: FAILURE in 5 hr 51 min: https://lpci.wedontsleep.org/job/db-devel/787/
[20:43] <sinzui> gary_poster, ping
[20:45] <gary_poster> sinzui: pong
[20:45] <sinzui> gary_poster, help.launchpad.net does not know about +structural-subscriptions. I cannot see a link to that page. How do users find it to manage their subscriptions.
[20:46] <gary_poster> sinzui, that page does not exist.  It is, if anything, an expert interface; something that we might have removed
[20:47] <sinzui> It certain does exist. I use ever several time a week to manage all mine and your subscriptions
[20:48] <sinzui> https://bugs.launchpad.net/~gary/+structural-subscriptions
[20:48] <gary_poster> sinzui, it is intentionally not part of our advertised UI.  It may go away without warning.
[20:48] <sinzui> okay
[20:48] <bac> gary_poster: that is the page that gavin put together, right?  it was never completed and our new work make it obsolete.
[20:49] <gary_poster> bac, correct on the first part.  I agree with your second part, but perhaps that is more arguable (and I have no interest in arguing it).
[20:50] <gary_poster> well, "never complete" is probably fairly factual as well
[20:50] <bac> gary_poster: yes, arguable.  but it was purposefully never linked to...a way to make it visible before feature flags
[20:50] <gary_poster> precisely bac
[20:50] <bac> my point being, it was never fleshed out and we didn't *remove* an existing link
[20:50] <gary_poster> right
[20:51] <sinzui> I do not believe that page is obsolete because it partially addresses a very old issue. Users want a single place to see all their subscriptions
[20:52] <sinzui> The new work is not hooked into the the user/team bug listing. But I can use the new listing to control multiple subscriptions. I also delete a lot from ~registry
[20:56] <gary_poster> I hear you sinzui.  However, it was never worked to be considered release-worthy as is, and not deemed important enough by the mgmt to be completed.  We did not remove it in part because you have repeatedly mentioned that you use it.
[20:56] <gary_poster> However, in terms of "release features when they are done," this was not done.  If I had had more balls, I suppose I would have ripped it out despite everything, because that would have fit in with the decisions around me.
[20:57] <gary_poster> I did not, and it is no now longer part of my domain in particular--the feature is done.
[20:57] <gary_poster> our work on it, at least.
[20:57] <sinzui> understood. I am just addressing user (bug supervisor) concerns that they receive unwanted email
[20:59] <gary_poster> I would have expected that they could manage that via the link in their emails, sinzui (to the equivalent of https://bugs.launchpad.net/launchpad/+bug/240067/+subscriptions).  Expanding "Other subscriptions" should show everything pertinent.
[20:59] <_mup_> Bug #240067: Launchpad projects need wikis <feature> <lp-foundations> <ubuntu-platform> <Launchpad itself:In Progress by xaav> < https://launchpad.net/bugs/240067 >
[20:59] <gary_poster> And let them manage it.
[21:00] <gary_poster> But maybe there's something special about this case that makes that unusable for some reason
[21:00] <sinzui> gary_poster, when you get hundred of emails, you do not want a research project to end them. The angry user wants a summary of what went wrong and the power to fix it
[21:01] <gary_poster> sinzui, yes.  The intent was that you click on a link in an email you are angry about, and fix it.
[22:46] <LPCIBot> Project devel build #952: FAILURE in 5 hr 59 min: https://lpci.wedontsleep.org/job/devel/952/