[00:02] <mwhudson> lifeless: did you find out what was going on with your query counts yesterday?
[00:05] <rexbron> hey jelmer
[00:13] <lifeless> mwhudson: very sure its the storm bug with calling _init early
[00:13] <lifeless> mwhudson: its a cache-reuse triggered bug
[00:14] <lifeless> mwhudson: so I just added fuzz and landed
[00:14] <mwhudson> lifeless: ok
[00:14] <lifeless> r 11742 if you want to see the comments
[00:18] <lifeless> is is safe to use with security proxied things
[00:35] <lifeless> mwhudson: ^
[00:47] <lifeless> thumper: ^ do you know ?
[00:48] <thumper> lifeless: ENOTENOUGHCONTEXT
[00:49] <lifeless> for person_or_team in iterator:
[00:49] <lifeless>   if person_or_team is self.user
[00:49] <lifeless> would that be safe? or does is work too deep and be false if person_or_team had a new proxy instance wrapped around it ?
[00:51] <thumper> I think safer to use ==
[00:52] <thumper> as that goes through the proxy whereas is doesn't
[00:53]  * mwhudson too
[00:53] <lifeless> I wrote it as .id == ....id
[00:53] <lifeless> because of concerns about is
[00:53]  * lifeless chalks up another downside of sec proxies
[01:01] <mwhudson> is there some command line tool you can run to pop up a notification?
[01:01] <mwhudson> (not a launchpad question!)
[01:03] <ajmitch> mwhudson: libnotify-bin package looks like it has something
[01:03] <mwhudson> ajmitch: yeah
[01:03] <mwhudson> just found that myself
[01:03] <mwhudson> thanks :)
[01:03] <ajmitch> not that I've used it :)
[01:16] <lifeless> spm: losa ping :P
[01:16] <spm> yo
[01:16] <lifeless> spm: I wants to know if staging's restore is working
[01:17] <lifeless> or gone off the rails
[01:17] <spm> bit of column A, bit of column B
[01:17] <lifeless> (its been 5 hours I think, now)
[01:19] <spm> hrm. it's doing a full restore; so ETA is probably around 5-15 hours. I'm not sure why it's down atm tho. should be using the main DB. I suspect something else broke spectacularly and hence...
[01:27] <lifeless> spm: so it can be brought up ?
[01:28] <spm> I don't know, I'll try. just need to unpack a few layers of interrupts first.
[01:29] <lifeless> kk
[01:29] <lifeless> spm: is it safe fo rme to use the staging ro connection from devpad ?
[01:30] <spm> yup; the update is into a separate DB
[02:33] <lifeless> mwhudson: UPDATE CodeImportMachine SET heartbeat=CURRENT_TIMESTAMP AT TIME ZONE $STRING WHERE CodeImportMachine.id = %s: - well on its way to being the top oopser on lpnet
[02:33] <lifeless> c
[02:37] <spm> lifeless: just brought up staging app (only), it *seems* happy, but subect to failure without warning. be warned.
[02:37] <lifeless> hah, thanks
[02:42] <mwhudson> lifeless: should be an easy fix to only update if the heartbeat is more than 30 secs old or something
[03:07] <lifeless> wow
[03:07] <lifeless> 40 queries for a fresh product +assignments page with 10 specs.
[03:09] <mwhudson> wow high or wow low? :-)
[03:09] <mwhudson> i would have believed much worse
[03:10] <lifeless> high
[03:10] <lifeless> I'm an optimist
[03:11] <wgrant> That sounds really good to me. Considering it's ancient and... well.. Blueprint.
[03:11] <lifeless> wgrant: one word
[03:11] <lifeless> ValidPersonCache
[03:11] <wgrant> Hah.
[03:11] <lifeless> bug 618367
[03:11] <_mup_> Bug #618367: Distribution:+assignments is taking a long time maybe 20% of the time <timeout> <Launchpad Blueprints:Triaged> <https://launchpad.net/bugs/618367>
[03:11] <mwhudson> lifeless: the good news is that the code is probably so stupid/naive that fixing it will be simple
[03:12] <lifeless> mwhudson: good god you're an optimist too
[03:12] <mwhudson> lifeless: well, compared to fixing a +translate timeout or something
[03:12] <lifeless> check out lib/lp/blueprints/model/specification.py
[03:12] <lifeless> line 748
[03:13] <lifeless> yes. Its string-concatenation-to-build-sql time.
[03:14] <mwhudson> with a side of "oh god can we just delete projects not deactivate them please"
[03:14] <mwhudson> though at least you can do left outer joins with storm
[03:15] <lifeless> but not full outer :P
[03:16] <mwhudson> anyway, it's horrible, but at least that method only generates one query
[03:16] <lifeless> ah
[03:16] <mwhudson> lifeless: does the bug require a prepopulation type fix?
[03:16] <lifeless> but it sets things up to generate 200 others
[03:16] <lifeless> yes
[03:16] <mwhudson> i see
[03:16] <lifeless> is_valid_person
[03:17] <ajmitch> mm, blueprints - why do I never hear good things about it in here?
[03:17] <lifeless> give you one guess?
[03:17] <ajmitch> it's shit?
[03:17] <lifeless> its unmaintained
[03:17] <lifeless> and
[03:17] <lifeless> its extremely close to bugs
[03:17] <persia> Has been for >4 years too, which only adds to the pain
[03:18] <ajmitch> which is why wgrant always wishes that it be destroyed
[03:18] <lifeless> there are variously held opinion about whether specs are even different enough to bugs to warrant the amount of unique code
[03:22] <wgrant> They're not.
[03:22] <wgrant> Kill them.
[03:23] <lifeless> well, if it was that easier :P
[03:23] <lifeless> self.context is the model object, right ?
[03:23] <wgrant> In general, yes.
[03:24] <lifeless> oh god
[03:24] <persia> wgrant, The one difference I find useful between blueprints and bugs is the ability to link a blueprint to an arbitrary external URL.  This used to be available for bugs, but doesn't seem to be around anymore.
[03:24] <lifeless> that place I referenced?
[03:24] <lifeless> not used by this code path.
[03:24]  * mwhudson gets ready to ship strong drugs to lifeless
[03:24] <wgrant> persia: And dependencies.
[03:24] <ajmitch> persia: the other useful thing that I can think of is the dependency graph
[03:24] <lifeless> Its not that theres duplication, its that there isn't sharing
[03:24] <wgrant> persia: Bugs don't have dependencies. This is probably a bug.
[03:25] <ajmitch> sprints, not so useful
[03:25] <lifeless> urk
[03:25]  * persia doesn't believe blueprint dependencies are any more meaningful than bug dependencies semantically, and kinda wishes they hadn't been implemented
[03:25] <mwhudson> wgrant: bug dependencies got added to the "to do, for real this time" pile recently i think
[03:25] <persia> ajmitch, sprint linking of bugs would be massively useful, assuming we had a sane way to manage sprints.
[03:25] <lifeless> bugs are getting relationships
[03:25] <wgrant> mwhudson: As they were at UDS Jaunty.
[03:25] <lifeless> one relationship will be dependency
[03:25] <ajmitch> one less reason to keep blueprints
[03:26]  * lifeless sobs
[03:26] <persia> lifeless, Why?  There were good and strong arguments about that being semantically bad.
[03:26] <lifeless> mwhudson: compare person.py specifications() and distribution.py, the same
[03:26] <lifeless> persia: because vastly more people want it than don't
[03:27] <mwhudson> lifeless: that's pretty special
[03:27] <lifeless> persia: FWIW no data was presented in the arguments AFAICR - they were - both sides - purely rhetorical
[03:27] <persia> It's not that I don't want them, so much as I know they cannot be managed in a sane way, and will lead to a maze of twisty little relationships, all different.
[03:27] <persia> Oh sure, it's all rhetoric and semantics.  There's no technical reason to do it one way or the other.
[03:27] <lifeless> persia: a specific case that relationships in general are needed for is this:
[03:28] <lifeless> some customers with private bugs have complex relationships
[03:28] <lifeless> where bug tasks expose too much data
[03:28] <lifeless> e.g. two or three of *their* customers need to collaborate in little partitions on their own slice of the thing, and not know about each other
[03:28] <persia> Ah, so private -> public dependencies are required for management of certain commerical relationships?
[03:29] <lifeless> I'm sure there are a variety of uses all in the partial-disclosure space.
[03:29] <persia> Oh, slices.  hrm.  That raises the spectre of implementing a project management solution.
[03:29] <persia> (which would be a good thing, and for which there are nice mock-ups available)
[03:30] <lifeless> man, this code really needs a complete overhaul.
[03:30]  * lifeless fixes the proximate cause and walks away softly
[03:30] <ajmitch> it's not the easiest code for someone to walk up to & fix
[03:32] <mwhudson> when estimating a blueprints change recently i estimated 1 day to get over the nausea and 1 day to implement the feature
[03:32] <mwhudson> was about right
[03:48] <lifeless> sanity check
[03:48] <lifeless> limit=xxx in sqlobject ->
[03:48] <lifeless> resultset[:xxx] in storm
[03:48] <wgrant> Yes.
[03:48] <lifeless> and that returns a resultset to return - it doesn't actually evaluate
[03:48] <lifeless> ?
[03:49] <wgrant> It should return a ResultSet, yes.
[03:49] <wgrant> In fact it probably just calls .config(limit=blah)
[03:50] <lifeless> this is probably going to be one of these disastrous rabbit holes
[03:51] <wgrant> More than likely.
[03:51] <lifeless> and what are you doing this fine performance tuesday?
[03:54] <wgrant> Uh, trying to wrangle a none-too-useful project team.
[03:58] <lifeless> I will live in hope for next week then
[03:59] <lifeless> whats the standard idiom to add another column to return to an existing resultset ?
[04:00] <lifeless> also
[04:00] <lifeless> do you have to us 'using' when doing outer joins ?
[04:00] <lifeless> or can you just put it in the expr list ?
[04:05] <mwhudson> i don't think you have to use using in that situation
[04:05] <mwhudson> although i forget when you can
[04:07] <lifeless> its sad that I want to write static methods to avoid fucking with interfaces.
[04:07] <lifeless> s/sad/predictable/
[04:14] <wgrant> lifeless: What's so bad about changing the interface?
[04:22] <lifeless> wgrant: we have neither the toolchain support of java, nor the ease of use of python.
[04:23] <lifeless> wgrant: and, AFAICT, not much benefit from it. I may be being slightly harsh.
[04:32] <lifeless> wgrant: there are, to my knowledge, two uses from most of the interfaces we use:
[04:32] <lifeless>  - security proxies : a performance *nightmare*.
[04:33] <lifeless>  - API generation : so far it seems to have a high cost for generating a high performance API itself
[04:33] <mwhudson> lifeless: how would you do authorization if you could throw away security proxies?
[04:34] <mwhudson> i'm genuinely curious, the django approach ("explicitly check in all your view methods") seems lame
[04:34] <lifeless> mwhudson: I'd like to define it in the mapping layer
[04:35] <lifeless> so that we only get back from the db stuff one can see (covers View)
[04:35] <lifeless> mm let me rephrase
[04:35] <lifeless> I think there are several different *sorts* of thing one wants from security
[04:35] <lifeless> theres disclosure
[04:36] <lifeless> theres permission (yes, you may add yourself to the team)
[04:36] <lifeless> maybe others
[04:36] <persia> accounting: who did what.
[04:36] <lifeless> anyhow, we do a bit of a mix of disclosure and permission via security proxies
[04:36] <mwhudson> yeah
[04:36] <mwhudson> well
[04:36] <lifeless> persia: not catered for by the tech we're talking about
[04:36] <mwhudson> it's all squashed into disclosure
[04:36] <lifeless> persia: for all that it is true that one wants it
[04:37] <lifeless> so, when I look at our code
[04:37] <persia> Ah, if you7re concentrating on the middle 'A' of 'AAA', then never mind.
[04:37] <lifeless> I see adhoc stuff for permission
[04:37] <mwhudson> lifeless: well, to some extent we do use interfaces for accounting via Snapshot
[04:37] <lifeless> I have, I think, a reasonable answer for disclosure
[04:37] <lifeless> mwhudson: I'm not across snapshot yet, I need to do that
[04:38] <mwhudson> but certainly not proxies
[04:38] <lifeless> the answer for disclosure is 'dont retrieve what thou dost not want'
[04:38] <lifeless> which we want in a very definite way for many reasons
[04:38] <lifeless> performance being a prime one
[04:38] <mwhudson> and very slowly and ad-hocily we're heading in that direction
[04:39] <lifeless> I think that making the permission checks be all done via e.g. decorators on methods could be nice
[04:39] <persia> lifeless, Take a care there: some of the current state of that comes from not checking for authorisation for direct requests to stuff normally not wanted.
[04:40] <persia> (otherwise known as URL crafting attacks)
[04:40] <lifeless> I certainly would like to have /one way/ to do 'yes you can do that' checks, rather than some security proxied, and some written in-line, and some via some other way I've temporarily forgotton
[04:40] <lifeless> persia: huh?
[04:41] <lifeless> persia: I fail to follow your reasoning; hitting up a url you don't have access too will result in the DB mapping layer returning no record and the attacker seeing a 404, in what I'm proposing.
[04:41] <persia> Ah, OK.  I just misunderstood then.  I'll stop inserting stuff.
[04:42] <lifeless> the big question is, what should happen if someone makes a programming mistake
[04:42] <lifeless> and includes inappropriate results in a mapping output
[04:42] <mwhudson> lifeless: indeed
[04:42] <mwhudson> 'fail-closed' is one nice property security proxies have
[04:42] <lifeless> with our current approach, we bypass the security proxy and lie to it.
[04:43] <lifeless> mwhudson: we gave it up quite a while back.
[04:43] <mwhudson> .. when we don't do that
[04:43] <lifeless> We have three - three! different mechanisms for doing this, that I know of.
[04:43] <lifeless> mwhudson: I guess I don't have solid answers yet.
[04:44] <lifeless> right now code cleanliness is at the bottom of my hit-list.
[04:44] <lifeless> by which I mean this whole discussion :)
[04:45] <lifeless> persia: your interjections are welcome, but you may need to focus very closely and look at the LP code to see the context and issues being discussed.
[04:46] <persia> lifeless, Thanks.  More I'm stopping on this discussion, because I'm insufficiently familiar with that bit of code.  I didn't mean that I'd not interject more in the future, but unless I *know* the code, it makes sense to stop at a point, or it wastes everyone else's time.
[04:51] <thumper> mwhudson: in what way does etags help bash?
[04:52] <mwhudson> thumper: you can go M-. on a function call and jump to the defintion
[04:52] <mwhudson> like anything else
[04:52] <mwhudson> thumper: large parts of lexbuilder are in bash
[04:52] <thumper> ah
[04:52] <thumper> ok
[04:57] <thumper> anyone know how to find a branch that is linked to a translation series?
[04:57] <thumper> any one would do
[04:58] <thumper> I'm testing deletion on staging
[05:00] <lifeless> thumper: can I give you a quick ring; needs a teddy bear
[05:00] <thumper> ok
[05:12] <lifeless> select * from specification inner join person on (specification.assignee=person.id or specification.drafter=person.id)
[05:27] <lifeless> hmm
[05:27] <lifeless> diff updating is the slow ?
[07:13] <lifeless> spm: when does edge update?
[07:13] <spm> lifeless: https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadProductionStatus#Edge%20Updates 0800 BST, until lucidified, then 0800UTC
[07:14] <lifeless> so bah, an hour
[07:14]  * lifeless wants his fix from yesterday online
[07:14] <lifeless> and a pony
[07:14] <spm> shiny pony?
[07:14] <lifeless> mmm shiny shiny horses
[07:15] <spm> its a tradeoff. we've had cases where - and almost guaranteed when we're on a sprint - that edge has failed; so the above time is a fair balance to ensuring minimal pain and suffering all round.
[07:15] <lifeless> oh, I know
[07:15] <lifeless> and we're making it manual as soon as rt 4whatever is done
[07:15] <lifeless> but the tradeoff is that we'll then be asking many times a day
[07:16] <lifeless> :)
[07:16] <spm> ....
[07:16] <lifeless> spm: ....
[07:16] <poolie> lifeless: should i think about why curtis ran in to trouble with flags, or delete it from my mind?
[07:16] <poolie> it's not obvious to me how i broke him
[07:16] <lifeless> poolie: he's ported your devel work to production
[07:16] <lifeless> its been CP'd and is live I believe (spm can confirm)
[07:17] <poolie> devel meaning db-devel?
[07:17] <lifeless> poolie: devel and db-devel
[07:17] <lifeless> all are in sync now I believe.
[07:17] <lifeless> devel, db-devel, production-devel
[07:17] <spm> it's not yet been CP'd, about to bee, not yet.
[07:17] <lifeless> the skew was between (devel, db-devel) and (production-devel)
[07:17] <spm> too many other things keep breaking and demanding attention.
[07:18] <lifeless> if you want to mentate on it for your own edification, sure, but the issue is resolved.
[07:19] <poolie> at this point i only want to know if i need to do something differently next time
[07:19] <lifeless> uhm
[07:20] <lifeless> basically if changing something that someone may want to CP a fix which depends on the API, make it clear its changed and they'll need your patch too
[07:20] <lifeless> we're going to eliminate doing CP's as much as possible though by rolling out stable
[07:20] <lifeless> so I don't think ou need to alter what you do
[07:23]  * StevenK looks at buildbot, frowning
[07:33] <lifeless> StevenK: and b) what don't you know
[07:34] <lifeless> I mean, what threads have you got to pull on
[07:35] <StevenK> lifeless: It seems that tests that require other services randomly fail
[07:36] <StevenK> Or, mostly
[07:36] <lifeless> other services being librarian et al?
[07:36] <lifeless> we should have -nothing- needing internet access
[07:37] <StevenK> lifeless: Things like windmill tests, and tests talking to the xmlrpc service, for example
[07:37] <lifeless> windmill tests seem to be incredibly fragile
[07:37] <lifeless> they seem to timeout a lot
[07:38] <lifeless> maris comes to mind as the go-to guy to understand whats going on and how other folk have debugged it
[07:38] <StevenK> Maris is difficult to talk to :-)
[07:38] <StevenK> (Only due to timezones)
[07:38] <lifeless> I can haz email!
[07:39] <StevenK> lifeless: Meh
[07:39] <StevenK> :-)
[07:39] <lifeless> some things I'd do - run the test in isolation
[07:39] <lifeless> (via hudson)
[07:39] <lifeless> does it work ? yes, perhaps resources were an issue
[07:39] <lifeless> are you testing devel? devel breaks. they might be real breaks.
[07:39] <lifeless> try testing stable until you've got it robust
[07:39] <StevenK> lifeless: Right, but the same tests keep coming up time and time
[07:39] <StevenK> time and again
[07:40] <lifeless> so, is there enough memory, is the box swapping
[07:40] <lifeless> etc
[07:40] <lifeless> brb
[07:41] <StevenK> It's certainly not OOM'ing, but it will probably swap a little
[07:47] <StevenK> lifeless: Or we just throw builds at EC2/UEC and see if they stick
[08:19] <lifeless> you could do that too
[08:35] <lifeless> spm: is it me, or is the edge update running late?
[08:36] <spm> or broken...
[08:36] <spm> blew up. kickin manually
[08:36] <spm> Oh. no. it can't work. sodium's dead.
[08:36] <lifeless> hmm, we're getting
[08:36] <lifeless> Exception exceptions.AttributeError: "'NoneType' object has no attribute 'close'" in <bound method SmartSSHClientMedium.__del__ of SmartSSHClientMedium(bzr+ssh://launchpad-pqm@bazaar.launchpad.net/)> ignored
[08:36] <lifeless> Exception exceptions.AttributeError: "'NoneType' object has no attribute 'close'" in <function terminate at 0x13b3938> ignored
[08:36] <lifeless> in cron spam now
[08:36] <lifeless> poolie: ^
[08:37] <lifeless> pqm@devpad> $HOME/bin/update-launchpad-built-code.sh
[08:37] <lifeless> poolie: you should be able to see that, when sodium comes to life
[08:37] <lifeless> spm: what went wrong ?
[08:37] <spm> [17:36:42] <spm> Oh. no. it can't work. sodium's dead.
[08:38] <lifeless> spm: oh, you mean the edge update depends on sodium, the machine with a hernia?
[08:38] <spm> yup
[08:38] <lifeless> for some reason I though praé ran it
[08:39] <lifeless> whats the status of sodium, hyperbole aside
[08:39] <spm> for hysterical raisins, sodium is still a critical path in the build.
[08:39] <spm> needs physical visitation to stab
[08:39] <lifeless> wheres nafallo :P
[08:39] <lifeless> and I don't mean 'why isn't he in this IRC channel'
[08:40] <lifeless> we need an rfid chip in his goatee
[08:40] <lifeless> spm: I thought we had fancy remote-power stuff
[08:40] <adeuring> good morning
[08:40] <spm> lifeless: we do, that's not the problem
[08:41] <lifeless> oh
[08:41] <poolie> lifeless: that looks like the bug someone reported the ohter week?
[08:41] <lifeless> spm: what happened
[08:41] <lifeless> poolie: yes, they were reporting it in 'ec2 land', this is a different script but I suspcet the same root cause; its not harmful, other than a) scary and b) causing cron to mail losas
[08:49] <poolie> i wonder if there is a bug
[09:15] <lifeless> spm: did it falter?
[09:15] <spm> nope; still going
[09:15] <lifeless> ah
[09:15]  * lifeless urges it on
[09:15] <jkakar> lifeless: Here now.
[09:16] <lifeless> jkakar: Ah, you're back home, of course.
[09:16] <lifeless> jkakar: I was fighting the good fight with storm
[09:16] <jkakar> lifeless: :)
[09:25] <spm> lifeless: give it a whirl now?
[09:25] <lifeless> ok cool. lets see if the api is better
[09:26] <lifeless> woo
[09:26] <lifeless> https://api.edge.launchpad.net/1.0/bugs/414746/attachments
[09:26] <_mup_> Bug #414746: speakers cannot be muted when using headphones regression (karmic) <apport-bug> <apport-collected> <i386> <regression-release> <pulseaudio (Ubuntu):Confirmed> <https://launchpad.net/bugs/414746>
[09:26] <lifeless> worked
[09:41] <lifeless> spm: might get a profile of the bugtask index page again once that patch has percolated to stable. I don't think it has yet.
[09:57] <adeuring> stub: could you look again at my MP with the schema patch for the "subscribe to search" feature?
[10:09] <lifeless> stub: hey
[10:09] <lifeless> stub: so ValidPersonCache bites again in specifications
[10:09] <lifeless> stub: I'm wondering if we can figure out whats up with it - why it peforms so terribly
[10:09] <wgrant> DELETE
[10:09] <lifeless> I mean, we can eliminate all uses of it eventually
[10:12] <lifeless> wgrant: read much Gordon R Dickson ?
[10:12] <wgrant> lifeless: None.
[10:13] <lifeless> jkakar: My perf tuesday mail today, + storm backlog, should cover all the salient points if you're interested in the things I'm rubbing up against.
[10:14] <jkakar> lifeless: Am very interested, will check it out.
[10:15] <jkakar> lifeless: I'm not sure what to do about the LeftJoin+aliases issue.  It sounds tricky (I'm still digesting the problem).
[10:15] <stub> adeuring: done
[10:15] <adeuring> stub: thanks!
[10:15] <lifeless> jkakar: if Foo.reference compiled the same as Foo.reference_id, I think it would be fixinationed.
[10:16] <stub> lifeless: Think of a view like a macro. It gets expanded inline into the query that uses it before things get sent to the query planner.
[10:16] <lifeless> stub: does pg do materialized views ?
[10:16] <jkakar> lifeless: Perhaps it's as simple as that, yes.
[10:16] <stub> lifeless: No. You have to do them yourself using triggers.
[10:16] <lifeless> stub: the explain for the previous VPC thing we looked at had a 'materialising' line in it, which was -hugely- expensive
[10:17] <stub> lifeless: Yes, so PG decided it needed to dump that subplan into a temporary table for some reason.
[10:17] <stub> VPC?
[10:17] <stub> oh
[10:17] <lifeless> valid person cache
[10:18] <lifeless> sorry, long day :)
[10:18] <stub> headache :-)
[10:19] <stub> If using a view is slow a) Maybe unnecessary joins or clauses b) The expanded query blows chunks c) the expanded query is just slow.
[10:20] <stub> It wouldn't be too hard turning VPC into a materialized view if we want to keep it and it looks like being a common problem
[10:20] <stub> But the whole concept of 'valid' and 'invalid' people is wonky now we have accounts. And politically incorrect.
[10:22] <stub> ValidPersonCache actually used to be a materialized view, but had to be switched to a real view when we split the database into two replication sets when we where being an OpenId Provider.
[10:22] <stub> Or maybe I'm making that up. Fuzzy.
[10:24] <adeuring> stub: patch-2207-08-0.sql is already in use ;)
[10:24] <stub> adeuring: So we start the filter from 'all tags' or 'no tags' and then adjust that using the BugSubscriptionFilterTag values. Does that mean that the 'include' column there is unnecessary?
[10:25] <stub> adeuring: Whoops. patch-2207-09-0.sql then
[10:25] <adeuring> stub: no, we need that one too, for things like "foo -bar".
[10:25] <adeuring> stub: that patch number is used too ;)
[10:26] <stub> Really?
[10:26] <adeuring> 2207-81 seem to be unused
[10:26]  * stub wonders wtf happened to his tomboy notes
[10:26] <stub> Argh...
[10:26] <adeuring> erm, 2207-82
[10:26] <stub> 2208, not 2207. You need to merge db-devel
[10:26] <adeuring> stub: arg, thanks!
[10:27] <stub> adeuring: So patch-2208-08-0.sql
[10:27] <adeuring> stub: ok
[10:35] <lifeless> poolie: btw the O(N^2) analysis you did back at the epic on the bug attachments api - spot on
[10:36] <lifeless> poolie: I have landed a bandaid that avoids the N^2 on attachments but is N on messages, so not ideal, but tolerable
[10:37] <poolie> oh thanks
[10:41] <poolie> we just need more transparency, and faster landing of fixes, istm
[10:41] <poolie> "just"
[10:46] <jtv> lifeless: you emailed about count(*) not being cheap…  anything specific you had in mind, or just adding general advice?
[10:46] <lifeless> jtv: general advice
[10:47] <lifeless> jtv: it was a thing that came up in a few places in the epic & discussions since
[10:47] <lifeless> uhm, like about apis, and portlets, and so forth.
[10:48] <lifeless> jtv: only had your name in the header cause thats what reply-all did, wasn't targeted at you per se
[10:48] <jtv> It may be worth a check that we no longer have count queries in cases where we just want to know "zero or one," or "count up to x."
[10:48] <jtv> In fact, maybe "count up to a maximum of" could be a useful feature for an ORM.
[10:49] <jtv> gah head need lie down
[10:49] <lifeless> go get well
[10:53] <jtv> thanks—it's not that bad, really, just pacing myself
[12:00] <deryck> Morning, all.
[12:02] <lifeless> deryck: heya
[12:02] <lifeless> deryck: I'm heading to be, but I hope you have a great performance tuesday.
[12:02] <lifeless> deryck: I also have some good news for you (at the bottom of my perf tuesday mail i sent to the list)
[12:03] <deryck> ah, good news! :-)  Let me look then....  and good night, too, lifeless  :-)
[12:05] <deryck> awesome news!  and bryceh will be glad too.
[12:06] <lifeless> I've mailed leann to let her know to use edge for a couple weeks
[12:06] <lifeless> deryck: something weird for me though
[12:06] <lifeless> on launchpad.dev
[12:06] <lifeless> https://bugs.launchpad.dev/redfish/+bug/15/+index
[12:06] <_mup_> Bug #15: PO file import errors should be more verbose <feature> <Launchpad Translations:Fix Released by carlos> <https://launchpad.net/bugs/15>
[12:07] <lifeless> the subscribption widget doesn't show subscribers
[12:07] <lifeless> is that js based?
[12:07] <lifeless> local-js seems borkinated for me, or something
[12:09] <lifeless> yes, definitely that - I see a +, not a pen, running firefox in the vm i s alittle better but still not right
[12:09] <deryck> hmmmm
[12:10] <deryck> So the subscriber's list is loaded via an XHR call
[12:10] <deryck> if this fails, you won't see subscribers.
[12:10] <lifeless> that would match
[12:10] <lifeless> this is for bug-607935
[12:11] <lifeless> where I have a massive improvement in query counts but something broke (which tests caught), I'm trying to see if it looks sane locally.
[12:11] <lifeless> I'll dig in the morning
[12:11] <lifeless> we'll cross paths I'm sure
[12:11] <deryck> the page could be oopsing.  You can load it directly.  Just look via inspector or firebug to see what url the page wants to load.
[12:11] <deryck> lifeless, ok, sure.  Talk to you then.  Rest well.
[12:11] <lifeless> (or perhaps you could pull lp:~lifeless/launchpad/bug-607935
[12:11] <lifeless> :!bin/test -vvt lib/lp/bugs/tests/../stories/bug-privacy
[12:12] <lifeless> demonstrates the failure
[12:12] <lifeless> only if you have the time, of course.
[12:13] <deryck> sure, I don't mind looking.
[12:15] <lifeless> *really* gone; past 11 :P
[12:15] <lifeless> gnight
[16:10] <rexbron> just a thought on how to improve the recipe service: https://bugs.edge.launchpad.net/launchpad-code/+bug/627466
[16:10] <_mup_> Bug #627466: Use a recipe branch instead of copy paste for source package recipes <Launchpad Bazaar Integration:Opinion> <https://launchpad.net/bugs/627466>
[16:38] <jelmer> rexbron, I'm not sure I follow - do you mean putting a single recipe file in a branch?
[16:38] <rexbron> jelmer: basically
[16:38] <rexbron> I like to keep the recipe files in bzr
[16:39] <rexbron> but when I commit and push
[16:39] <jelmer> rexbron: My guess would be that we'd eventually be able to move towards using a single branch with nested trees that get updated, instead of a recipe.
[16:40] <jelmer> rexbron: Are you updating your recipes particularly often?
[16:41] <rexbron> jelmer: at least for the first little while
[16:41] <jelmer> I find that I don't change them after I've put them up.
[16:42] <rexbron> jelmer: just a thought :)
[16:58] <noodles775> Originally we'd hoped to make it an option to re-use, or easily-update a recipe for the project when creating a branch: https://dev.launchpad.net/BuildBranchToArchiveUI/UseCaseDailyBuild
[16:58] <noodles775> but we didn't have the resources to implement it.
[16:59] <noodles775> rexbron, jelmer ^^
[16:59] <noodles775> Night all.
[16:59] <jelmer> g'night noodles!
[18:11] <mfraz74> What is happening with the Google Earth API change?
[19:07] <lifeless> morning
[19:07] <deryck> lifeless, was just about to email you
[19:07] <deryck> found your test failure
[19:07] <lifeless> \o/
[19:08] <deryck> http://pastebin.ubuntu.com/486417/
[19:08] <deryck> form validation was failing, causing the subscription to not truly be removed
[19:08] <lifeless> haha
[19:08] <lifeless> awesome
[19:08] <lifeless> I wonder
[19:08] <lifeless> is that logic even Needed on GETS ?
[19:08] <lifeless> if its only used to process subs ?
[19:10] <deryck> lifeless, I'm fairly confident it's only used for the +subscribe view, not bugtask index.  So GET for the +subscribe view, yes.  Not for bugtask index.
[19:10] <deryck> same view for two pages
[19:10] <lifeless> ah
[19:11] <deryck> Making it conditional on which view or splitting this into two views would definitely save some work on bugtask index.
[19:11] <lifeless> I'll file a bug for that
[19:12] <lifeless> it should be efficient enough now to be out of the way for folk analysing timeouts on +index
[19:12] <lifeless> thank you -very- much
[19:13] <deryck> np.  Was a fun curiosity to dig into.
[19:13] <lifeless> I hope it didn't take up too much time
[19:13] <deryck> lifeless, nah.  And thank you soooo much for the work you're doing on performance!
[19:15] <lifeless> my pleasure
[19:20] <lifeless> bah, my blueprint branch also had a -single- test failure in ec2
[19:21] <lifeless> hola mpt
[19:21] <mpt> hi lifeless
[19:21] <jelmer> 'evening deryck, lifeless
[19:22] <deryck> hi jelmer
[19:31] <benji> wgrant: I hear that you have a launchpadlib script that I should take a look at.
[19:33] <lifeless> benji: its 0432 for him. Good Luck.
[19:34] <benji> heh
[19:40] <lifeless> leonardr: how long till your EOD ?
[19:40] <lifeless> SpamapS has some APIs stuff he wants to ask, about jsonp, and i figure you'll be important for answering :)
[19:40] <leonardr> lifeless, 2 hours and change
[19:41] <SpamapS> leonardr: am hoping the public data in launchpad's API can be exposed via JSONP to allow AJAX calls directly to api.launchpad.net
[19:46] <leonardr> SpamapS, yeah, we can do that
[19:47] <SpamapS> leonardr: I'd even be interested in doing the dev work on it myself. :)
[19:49] <leonardr> SpamapS, ok, this would go into lazr.restful. the callback would be passed in with a query string argument called ws.invoke or something
[19:52] <SpamapS> leonardr: any thoughts on the data security implications? JSONP does sort of discard the XSS controls that would normally keep launchpad's data safe from other nastiness on a page.
[19:53] <leonardr> well, api.launchpad.net doesn't know who you are, so no private data will show up
[19:55] <leonardr> launchpad.net knows who you are, but we could decide to only allow jsonp on api.launchpad.net
[19:56] <cr3> what's the difference between a project group and just a project? and what's the class for just a project?
[19:58] <lifeless> the class for project is product
[19:58] <lifeless> the class for project group is project
[19:58] <lifeless> a project group aggregates projects
[19:58] <lifeless> its useful for instance for launchpad which has 15 or so separate projects in its umbrella
[19:59] <cr3> lifeless: gotcha, I didn't make the leap to product
[19:59] <lifeless> Roughly project -> project group as source-package->distro
[19:59] <lifeless> this is a piece of _massive_ techdebt
[20:08] <SpamapS> lifeless: did you have other thoughts on how to get those bug lists btw?
[20:08] <lifeless> SpamapS: do you have an exmaple url?
[20:08] <SpamapS> lifeless: if I could iframe something that has the same table content as this: https://bugs.launchpad.net/~clint-fewbar/+assignedbugs  that would be fantastic.
[20:09] <lifeless> SpamapS: rendered and all ?
[20:10] <lifeless> there is probably/possibly a template just for it
[20:10] <SpamapS> lifeless: at the moment, I'm working around the fact that I have zero server side scripting capabilities in the WI tracker.
[20:10] <lifeless> oh
[20:10] <lifeless> you could just move it to a better box:)
[20:11] <SpamapS> Yes, I'm at least trying to get 1 or 2 people to tell me to do that before asking IS for something. :)
[20:20] <cr3> when adding to long list of base classes in a class definition which is not completely alphabetically ordered, do I just add to the tail of the list? I'm thinking ordering might be important when base classes like IPillar or IServiceUsage are in the list of base clases, maybe those should be near the end as opposed to mine
[20:25] <lifeless> cr3: I really wish you were doing this adjacent to lp, not in the mix. I think it would go faster and end better.
[20:26] <cr3> lifeless: it's called hardware certification :)
[20:28] <lifeless> cr3: that one isn't really integrated in though, is it ?
[20:29] <lifeless> anyhow, to answer your question; I wouldn't touch the inheritance order. Its semantic, affects the MRO.
[20:29] <lifeless> sorting is only valid for nonsemantic lists.
[20:30] <cr3> lifeless: perhaps we have a different perception on how to go about having a results tracker adjacent to lp
[20:33]  * cr3 wouldn't mind taking a stroll in lifeless's brain for a while
[20:34] <lifeless> so what does 'integrated' mean
[20:34] <lifeless> To me it means that the lp UI would show links to result tracker data as appropriate
[20:34] <lifeless> but that its code wouldn't be responsible for that data
[20:35] <lifeless> probably use LP APIs as a backend
[20:35] <lifeless> (which would shake out a bunch of lurking performance issues for leonardr
[20:37] <cr3> lifeless: so have another web service running elsewhere which would expose a restful API, not so disimilar to LP, to be queried by views in LP and exposed to users that way?
[20:37] <lifeless> yes
[20:37] <lifeless> I *thought* that was precisely what we spoke about
[20:38] <cr3> lifeless: that was indeed precisely what we spoke about, but then I was given the impression by flacoste and jml that it should be in launchpad core because of all the concepts shared between LP and the Results Tracker: users, projects, source packages and maybe even branches
[20:38] <lifeless> I'm confused about the timeline though
[20:38] <lifeless> jml was not in montreal after the epic
[20:39] <lifeless> but you say that this guidance happened in montreal
[20:40] <cr3> lifeless: yes, I'm confused myself that I proposed to have this separate service in prague. I first pitched this idea to flacoste in berlin, then to him and jml in montreal.
[20:40] <cr3> lifeless: in prague, I'm very surprised I said this was still the approach agreed upon
[20:40] <cr3> lifeless: perhaps I said that this was the original design, but I apologize for having introduced this confusion
[20:41] <cr3> lifeless: on the other hand, I'm pleased to hear you liked my original idea :)
[20:41] <lifeless> I know that you need to be building a UI
[20:41] <lifeless> that is something I completely agree on
[20:41] <lifeless> and was clear in the QA room
[20:41] <lifeless> but that doesn't, to me, imply same database.
[20:42] <cr3> lifeless: regarding the UI, do you mean the dashboard rick spencer really wants?
[20:42] <lifeless> no
[20:42] <lifeless> whatever UI you build
[20:42] <cr3> API?
[20:42] <lifeless> you need to engineer towards the experience
[20:43] <cr3> lifeless: the experience at this point is mostly geared towards enabling platform folks to persist test results and expose an API so that they can expose their own UI
[20:43] <cr3> lifeless: until we observe a convergence in UI requirements, only then would it be worthwhile to actually expose one
[20:44] <cr3> lifeless: at this point, everyone seems to want a different UI so it's not worth investing time building one. just exposing an API would be extremely useful at this point
[20:44] <lifeless> I got a clear imagine in the QA meeting at the end of the platform sprint, that everyone wanted *a* UI to be built.
[20:46] <cr3> lifeless: that's probably the dashboard, but that's a placebo to workaround the fragmentation of results scattered all over the place
[20:47] <cr3> lifeless: in other words, the objective of that UI is to summarize information in a single location which the results tracker aims to do at the source
[20:48] <lifeless> Perhaps I'm out of the loop.
[20:49] <lifeless> *I* had the clear understanding that Marjo/Rick/Mdz wanted a use case - including UI - to be built up.
[20:52] <cr3> lifeless: my understand is that these are separate projects which currently address different concerns, which should eventually converge in due time. however, I'll double check with people which might have a better understanding than me :)
[20:52] <lifeless> what I want is the following:
[20:52] <lifeless> organisational:
[20:53] <lifeless>  - hnour jml's no-new-features-moratorium
[20:53] <lifeless>  - have all components in Launchpad maintained [unless you have ongoing can-be-interrupted time to fix issues, this would be an unmaintained component]
[20:53] <lifeless> technical:
[20:53] <lifeless>  - not add writes to an unscalable system
[20:54] <lifeless>  - not add stuff to a codebase we're already trying to split up into pieces
[20:54] <lifeless>  - have the tracker be really flexible and reusable
[20:54] <abentley> james_w`, with revno 104 of lp:bzr-builder, I get this: http://pastebin.ubuntu.com/486458/
[20:54] <lifeless>   - get it delivered quickly
[20:55] <cr3> lifeless: regarding the split, timing sucks unfortunately. if we were 12-18 months from now, that problem would probably be solved so I'd have precedent to work against. however, if I try to solve that problem and introduce the results tracker at the same time, I'm setting myself up for fail.
[20:56] <lifeless> cr3: not true; we have other things that collaborate with LP in different ways
[20:56] <lifeless> the Software centre agent
[20:56] <lifeless> login.ubuntu.com
[20:56] <lifeless> the UDD package importer
[20:56] <cr3> lifeless: ah, good to know. so are those examples of ways you envisionned the results tracker integrating with launchpad as a separate web service?
[20:57] <lifeless> they are all different, and none do quite what you want to do - but what you want to do is unclear to me because you're saying you don't need UI. Or something.
[20:58] <james_w`> abentley: that's wonky
[20:58] <james_w`> abentley: I can't diagnose the cause at this distance though
[20:58] <cr3> lifeless: I haven't committed to delivering a UI, but I'm still double checking
[20:58] <james_w`> abentley: getting the header line that it is parsing may help
[20:59] <cr3> lifeless: just got confirmation, the dashboard which will exose a summary of test results will eventually make use of the results tracker api in order to summarize some of its information
[20:59] <cr3> lifeless: so, the results tracker is still just about exposing an API at this point
[20:59] <lifeless> ok
[21:00] <james_w`> abentley: actually, that code looks very odd
[21:00] <cr3> lifeless: as mentionned earlier though, if we find a convergence in UIs created by people using the API, it might then be worthwhile to learn from that experience and expose a UI at that point
[21:00] <lifeless> given that, wouldn't it be simplest to just have it be a standalone API server, use API to ask LP things, and it can be queried directly.
[21:00] <abentley> james_w`, yes, it appears to be raising unconditionally.
[21:01] <james_w`> abentley: in the merge of your branch some code got deleted
[21:01] <cr3> lifeless: that was my original proposal, I guess I need to get back to jml about this. I'll hop online tonight to make sure in person.
[21:01] <abentley> james_w`, the try/except ValueError, right?
[21:01] <james_w`> yeah
[21:01] <lifeless> cr3: hes on leave
[21:02] <lifeless> cr3: for 2 weeks
[21:02] <cr3> lifeless: awesome!
[21:02] <lifeless> but
[21:02] <james_w`> abentley: it appears that I just deleted three lines from the file while merging
[21:02] <lifeless> if we have to interrupt him that is doable
[21:03] <abentley> james_w`, Ah.  Well, nobody's prefect.
[21:05] <cr3> lifeless: if I could have a quick twisted instance running with a restful interface on which I could start hacking, that might work for now.
[21:05] <james_w`> abentley: I apparently did: http://paste.ubuntu.com/486464/
[21:05] <james_w`> only the last hunk did I do intentionally
[21:05] <cr3> lifeless: my objective is to make people happy and to do so, having a prototype is good enough for now
[21:06] <cr3> lifeless: how would you suggest I proceed knowing I don't need to have anything actually integrated in launchpad before jml returns from his leave?
[21:07] <cr3> lifeless: also knowing this project might have to be folded into the core when he returns :)
[21:10]  * cr3 starts hunting for the software centre agent and login.ubuntu.com
[21:12] <lifeless> gary_poster: do you need me to dig up some help on the storm batching issue ?
[21:12] <lifeless> cr3: I'd talk to noodles about the csa
[21:12] <lifeless> and the software stack he used there
[21:12] <gary_poster> lifeless, oh, are you a storm guy too?  Yeah, that would be fantastic, thank you!
[21:13] <lifeless> no, but I play one on tv
[21:13] <gary_poster> :-)
[21:13] <lifeless> i was actually thinking of just grabbing jkakar in my evening
[21:13] <lifeless> showing him the bug and going 'pleeeease'
[21:13] <gary_poster> heh :-)
[21:14] <lifeless> niemeyer is around now though
[21:14] <gary_poster> I tired contacting him on privmsg but didn't get a reply
[21:14] <gary_poster> (jkakar)
[21:14] <lifeless> what the bug #
[21:14] <lifeless> (i've forgotten already :P)
[21:14] <gary_poster> bug 620508
[21:14] <_mup_> Bug #620508: Slicing a ResultSet breaks subsequent len() calls. <Storm:Triaged> <https://launchpad.net/bugs/620508>
[21:14] <gary_poster> oh, Jamu triaged it already, yay
[21:15] <cr3> I thought len always incurred a count(*)
[21:15] <lifeless> cr3: internal state in the resultset gets corrupted
[21:15] <james_w`> abentley: 0.5 released with your change and on it's way in to the bzr-builder ppa
[21:16] <lifeless> cr3: sliced = resultset[0:5]
[21:16] <abentley> james_w`, thanks!
[21:16] <lifeless> cr3: resultset.count() -> 5
[21:16] <james_w`> abentley: thanks for catching that
[21:16] <lifeless> or something along those lines
[21:16] <abentley> james_w`, np.
[21:16] <cr3> lifeless: hm, I can see how that could make sense but probably not what some people would expect :(
[21:17] <lifeless> cr3: its a bug
[21:17] <cr3> lifeless: feature? :)
[21:17] <lifeless> bug
[21:32] <lifeless> gary_poster: on assertions and the webservice
[21:32] <lifeless> gary_poster: it is you/benji/leonardr's call
[21:32] <gary_poster> lifeless: yes!  it is interesting topic
[21:32] <gary_poster> ok cool
[21:32] <gary_poster> thanks
[21:32] <lifeless> but if you want to tease out what I'm thinking/concerned about, I'm delighted to chat about it
[21:33] <gary_poster> I actually would love to, but I suspect the world would be better served by me trying to finish a review of one of stub's branches for now. :-)  If it arises again, though, I'll take you up on it
[21:33] <lifeless> kk
[21:49] <mwhudson> morning
[21:51] <gary_poster> hey
[21:55] <mwhudson> gary_poster: hello
[21:55] <gary_poster> :-)
[21:56] <mwhudson> gary_poster: have you been complained at about the 'bootstrap talks to the internet' issue?
[21:56] <gary_poster> mwhudson, no, but I took it upon myself to reply--oh!
[21:56] <gary_poster> and my reply was insufficient.
[21:57] <mwhudson> i haven't read my email yet today
[21:57] <mwhudson> though if it's a bug i might not be subscribed anyway i guess
[21:57] <gary_poster> It is bug 627159
[21:57] <_mup_> Bug #627159: codebrowse is taking around 10 minutes to startup <canonical-losa-lp> <Launchpad Bazaar Integration:New> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/627159>
[21:59] <gary_poster> mwhudson: codehosting is still edge-only, right?
[21:59] <gary_poster> eh, not that you'd necessarily know :-)
[22:00] <mwhudson> gary_poster: code*browse* is
[22:00] <gary_poster> mwhudson: er, yes, sorry, that's what I meant
[22:00] <gary_poster> thanks
[22:01] <mwhudson> gary_poster: what was confusing me was why something was looking for zc.buildout 1.5.1
[22:03] <gary_poster> mwhudson, if you don't tell the bootstrap what version to get of zc.buildout, it will go out looking for one.  zc.buildout is the only version specification that you have to specify twice, because bootstrap, unsurprisingly, runs before zc.buildout itself starts up to start honoring versions made in versions.cfg.
[22:03] <mwhudson> gary_poster: ok, but it was looking for 1.5.1 on edge, which doesn't access the internet -- how did it know about it?
[22:04] <mwhudson> maybe i'm misremembering things
[22:04] <mwhudson> gary_poster: also is there some way you can tell bootstrap to not do that?
[22:04] <gary_poster> mwhudson, I think you are remembering what happened on developer machines
[22:05] <gary_poster> tell bootstrap not to do that: yes, give it a version number, as we used to do, and shall do again
[22:07] <mwhudson> gary_poster: this was on staging: https://pastebin.canonical.com/36438/
[22:07] <mwhudson> (asuka)
[22:14] <gary_poster> mwhudson: ... asuka allows some requests through, or defining a download-base made it find 1.5.1 locally, or there's a code path I don't understand yet.  I'm pretty confident that specifying a --version will fix it though.  ...for the heck of it, I'll disconnect my dev box from the internet and run the branch that I believe fixes it and see if it works...
[22:15] <mwhudson> gary_poster: cool, it's a shame that such drastic steps are required to test this sort of thign :/
[22:16] <gary_poster> mwhudson, agreed.  (do you have any other ideas?)
[22:17] <mwhudson> gary_poster: not really; specifiying --version to bootstrap seems like a good idea
[22:17] <mwhudson> for testing, i can only think of vms
[22:19] <lifeless> what would that OS... oh
[22:19] <gary_poster> worked (though it revealed a Makefile bug)
[22:20] <cr3> lifeless: an idea I just had is that I could integrate with the launchpad interface without even modifying launchpad by using greasemonkey scripts pointing to the separate instance. for example, if I eventually expose a UI, the greasemonkey script could expose a button: show test results for this project :)
[22:20] <lifeless> cr3: put down the pipe, exhale, go get some freash air ;)
[22:20] <gary_poster> lol
[22:21] <cr3> lifeless: that's the problem, I just went for fresh air. no more of that for me!
[22:21] <gary_poster> :-)
[22:21]  * cr3 is sticking to smoking and hard liquor
[22:22] <cr3> lifeless: for your reassurance, I'm currently exploring a separate standalone service. I'll keep you posted/annoyed on my progress :)
[22:22] <lifeless> thanks!
[22:31] <gary_poster> mwhudson, do you have a few minutes for a review of the change pertinent to what we were discussing? https://code.edge.launchpad.net/~gary/launchpad/buildout/+merge/34251
[22:31] <gary_poster> it's small
[22:31]  * mwhudson looks
[22:31] <gary_poster> thanks
[22:32] <mwhudson> gary_poster: reviewed
[22:33] <gary_poster> thanks mwhudson
[22:33] <mwhudson> gary_poster: i wonder if we could block pypi.python.org using iptables or something in our ec2 test images?
[22:33] <lifeless> mwhudson: you can with security groups, I'm sure.
[22:33] <gary_poster> mwhudson, lifeless, should be even easier once we have tarmac/PQM back in the picture
[22:33] <mwhudson> i guess you could just whack '10.1.1.1 pypi.python.org' or something in /etc/hosts
[22:33] <gary_poster> then the machines will be in the DC
[22:34]  * gary_poster needs to reply to rockstar's email
[22:34] <mwhudson> lifeless: security groups only affect incoming connections afaik
[22:34] <lifeless> oh, hmm
[22:34] <rockstar> gary_poster, which email?
[22:34] <rockstar> Oh, tarmac one.
[22:34] <lifeless> rockstar: tarmac features
[22:34] <gary_poster> yeah
[22:34] <gary_poster> rockstar, can do it here if that works for you
[22:35] <rockstar> gary_poster, it doesn't, unfortunately.  I have to leave for class in 10 minutes.
[22:35] <gary_poster> rockstar: ok np :-)
[22:36] <lifeless> gary_poster: hi
[22:36] <gary_poster> Hey lifeless
[22:36] <lifeless> gary_poster: I realised another thing i want a few cycles to chat about with you
[22:36] <lifeless> I want to lower the global timeout more
[22:37] <gary_poster> ok
[22:37] <lifeless> but we have same pages which are all of:
[22:37] <lifeless>  - infrequently used
[22:37] <lifeless>  - extremely hard to optimise today
[22:37] <lifeless>  - slow
[22:37] <lifeless> so I've proposed and I think you were ok, with making the timeout overridable per page
[22:38] <lifeless> but
[22:38] <lifeless> this needs a unique-enough key to identify the page in the appserver
[22:39] <lifeless> I had been thinking to use the page id, but I'm not entirely sure now whether its uniqueenough
[22:39] <lifeless> or even appropriate
[22:39] <gary_poster> Yeah, not designed for that, from the get go
[22:40]  * gary_poster gets into handwaving mode
[22:40] <gary_poster> ...we could put it on view classes?
[22:40] <lifeless> :)
[22:40] <gary_poster> I expect you want it in a config file, but putting it in Python would probably be more expedent
[22:40] <gary_poster> i
[22:41] <lifeless> I was actually thinking to lookup (key) as a feature flag scope
[22:41] <gary_poster> I see...
[22:41] <lifeless> as long as (key) shows up in oopses, that would be a very low friction means to change this
[22:42] <lifeless> as in, a sysadmin could just do it, when a page starts blowing up in future, file a critical bug, we fix, rule gets removed returning it to the default
[22:42] <gary_poster> Yeah, I see how that's a compelling story.
[22:44] <gary_poster> Thoughts:
[22:45] <gary_poster> - full class name of view class?  Maybe this would be the start of a new take on page id, but for now we don't have to solve both stories at the same time.
[22:46] <lifeless> sure, we don't have to conflate the two things
[22:46] <gary_poster> - Zope does crazy crap with some of the zcml tags we use, making view classes on the fly.  They've been discouraged at ZC for years, for instance.  We use 'em because we have old code.  They would make a simple plane like the first bullet point harder
[22:46] <gary_poster> simple plan
[22:46] <lifeless> the key constraints in the short term are: - deterministic key; lookup in features; control per-request timeout if a feature rule is found
[22:47] <lifeless> + key shown in oops somehow
[22:47]  * mwhudson can attest to the crazy crap
[22:47] <gary_poster> :-)
[22:47] <lifeless> the uniqueness needed is that we should be identifying a code path reasonably precisely
[22:48] <lifeless> adding stuff to the oops is easy via the request vars dict, we can wedge it in any old how
[22:48] <gary_poster> - looking them up in features is a short-term requirement?  Seems like a short term very nice to have, but can see either way
[22:48] <mwhudson> specifying the behaviour in the browser:page directive?
[22:48] <lifeless> gary_poster: it is because:
[22:49] <lifeless>  - we don't know -completely reliably- whats going to go *boom* when we change the global timeout
[22:49] <lifeless>  - when we change it, we'll be flooded with issues, and the config system takes about 1.5 hours to make a change.
[22:49] <gary_poster> ack, conceded
[22:49] <lifeless> however, its not a big task - flags are darn easy to use.
[22:50] <gary_poster> the flags are not my concern; the keys are.  Just deciding on something and trying it wouldn't be the worst approach in the world, I suppose.
[22:51] <gary_poster> To pull out one thing you've said:
[22:51] <gary_poster> eh, no it was obvious
[22:52] <gary_poster> I was thinking about the fact that the OOPS reports are the tool you will use to analyze what needs to be don, not the performance reports, but of course, that's the way it has to be
[22:52] <lifeless> I would like to use a single key across the system, but thats long term not short term
[22:53] <gary_poster> agreed
[22:53] <gary_poster> on both
[22:53] <gary_poster> OK, lifeless, I have a few minutes before dinner.  Want me to put a bug in on this?
[22:53] <lifeless> please!
[22:53] <gary_poster> k, will do
[22:53] <lifeless> thank you
[22:54] <gary_poster> np
[22:56] <thumper> morning people
[23:01] <lifeless> matsubara: hey, around?
[23:01] <matsubara> lifeless, yes, about to leave
[23:01] <lifeless> matsubara: have you followed the thread about oops mails; do you have any thoughts? how hard are the changes discussed to do?
[23:01] <lifeless> matsubara: you could answer this tomorrow if you like
[23:02] <lifeless> I have one other question
[23:02] <lifeless> is it possible to lookup an oops by page id ?
[23:02] <matsubara> lifeless, I glanced over the thread. there are some changes easy to do (like disabling the weekly summary) others not so much. I can't really make any changes to that in the near future because I'm supposed to be helping the team with the new merge workflow. once the new merge workflow is mostly done, I can resume working on oops-tools again
[23:02] <lifeless> I have a low volume but consistent oops I want to analyse, its blocking lowering the timeouts
[23:03] <lifeless> matsubara: thanks for the feedback, yes, we're fully committed workloadwise ;)
[23:04] <matsubara> lifeless, currently, not it's not possible. but it's doable.
[23:04] <matsubara> s/not/no/
[23:05] <lifeless> ok, I'll grep... pity the server :)
[23:06] <wgrant> http://github.com/blog/712-pull-requests-2-0 is interesting.
[23:06] <wgrant> It looks... just like LP MPs.
[23:07] <lifeless> wgrant: indeed, interesting
[23:07] <gary_poster> lifeless, bug 627701
[23:07] <_mup_> Bug #627701: Make it possible to use feature flags to override the global timeout for specific pages <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/627701>
[23:07] <lifeless> gary_poster: thank you!
[23:08] <gary_poster> sure.  have a good day
[23:30] <thumper> wgrant: and not a single comment referring to prior art :)
[23:30] <thumper> or is that :(
[23:35] <wgrant> thumper: But it's innovative!
[23:40] <lifeless> well
[23:41] <lifeless> MP's don't refer to things that came before either
[23:49] <thumper> I was referring to the reader's comments, not the blog post writer
[23:54] <lifeless> sure, my bad
[23:54] <lifeless> ECAFFEINE, though at least the headaches are mostly gone now
[23:56] <lifeless> anyone run into 'ValueError: Supplied vocabulary values resulted in duplicate term tokens' before ?