[18:20] <lifeless> cr3: ol
[18:20] <lifeless> ola
[18:21] <nigelb> Morning lifeless :)
[18:21] <nigelb> Damn, its still yesterday for me.
[18:23] <lifeless> it always will be
[18:23] <lifeless> nigelb: hey, hows the jsoopsd going ?
[18:23] <nigelb> lifeless: Haven't started yet. Life.
[18:23] <lifeless> :)
[18:23] <cr3> lifeless: hola senor!
[18:24] <lifeless> cr3: I'm wondering how to get the service integration for the results tracker underway
[18:24] <lifeless> cr3: like e.g. should we identify a couple of useful steps and create bugs for the, ?
[18:24] <lifeless> s/the,/them/
[18:26] <cr3> lifeless: my understanding is that the next step consisting of auditing the code, does that sound about right?
[18:28] <cr3> lifeless: if so, I thought that perhaps having a production instance running might be useful which was completed last week. however, only IS has access to that instance, so I'm not really sure that was really a blocker come to think of it
[18:31] <lifeless> :)
[18:31] <lifeless> so the code review was part of being willing to open backend ports betwee it and LP
[18:31] <lifeless> we kindof need to do that & the first backend service at the same time
[18:32] <cr3> lifeless: what do you mean by "first backend service"?
[18:32] <lifeless> service call
[18:32] <lifeless> thing where it calls into LP via a trusted API
[18:32] <lifeless> e.g. direct person access
[18:33] <cr3> lifeless: ok, does LP already have direct person access?
[18:33] <lifeless> currently the only APIs for person at the launchpadlib ones - which means you'll run into trouble if the account is renamed
[18:33] <cr3> lifeless: btw, opening backend port can be done as one step and then actually using that port a second step
[18:34] <lifeless> sure, I kindof like to have a use case up my sleeve when changing firewall rules - so that someone monitoring can see it gets used.
[18:34] <cr3> lifeless: do you envision the person access needing a microservice of its own? how will that work?
[18:35] <lifeless> long term we might do a dedicated directory service, yes.
[18:35] <lifeless> medium term LP is the directory, so I'd expect targeted APIs on its services
[18:35] <cr3> lifeless: short term, database access? privileges launchpadlib api?
[18:35] <lifeless> 9
[18:35] <lifeless> bah
[18:35] <lifeless> no, no db access, ever ever ever ever evcer
[18:35] <cr3> good, I was going to whine otherwise :)
[18:35] <lifeless> possibly a privileged lplib API, or an xmlrpc api
[18:36] <cr3> lifeless: ideally, I'd like for the results tracker to still be runnable standalone by people on the outside. although that's my problem, just thought I'd share some of my pain :)
[18:37] <lifeless> cr3: thats a good goal, but there are two very distinct paths to it
[18:37] <lifeless> cr3: one path is to say 'run up as much of LP, *or equivalent services*, as the tracker needs'
[18:37] <lifeless> cr3: the other path is to say 'the tracker knows how to run standalone and how to run integrated'
[18:37] <cr3> lifeless: I could start looking into contributing a person access, any preference between lplib api or xmlrpc? I think there's more lplib api precedent for my inspiration, so that would be my inclination
[18:38] <lifeless> cr3: launchpadlib API only knows how to speak active urls; I don't think there is -any- precedent for using things that aren't exposed in the regular traversable fashion over lplib
[18:38] <cr3> lifeless: I was leaning towards the latter: being able to parameterize whether the tracker is running integrated or standalone
[18:39] <lifeless> cr3: that implies that you'll have two copies of every template, for instance (one for standalone, and one in the lp template service for integrated)
[18:40] <cr3> lifeless: I haven't even started thinking about the user interface, I'm hoping to find a way to make template sharing possible somehow
[18:41] <lifeless> cr3: If I were working on it, I wouldn't do a standalone mode; I would make the services it depends on clear, crisp, contracts, so that thin versions can be written and combined to run outside of LP
[18:41] <cr3> lifeless: maybe a tracker aware zope component that points to templates in the tracker codebase, I really don't know
[18:42] <lifeless> cr3: That sounds awfully complex vs saying 'templates are in the LP tree'
[18:42] <cr3> lifeless: to me, "LP tree" means it can't run standalone
[18:43] <cr3> lifeless: anyways, we'll burn that templates bridge when we're on it, lets concentrate on the person access service for now :)
[18:44] <lifeless> so to define it, we need to figure out what data you need, and in what access patterns, so that you can drop your mirrored person table
[18:44] <lifeless> (or reduce it to non-duplicated data [e.g. an enterprise-wide person reference]
[18:44] <cr3> lifeless: I'm not sure I understand "aren't exposed in the regular traversable fashion", I was thinking something like the hwdb in the lplib api which is only accessible to members of a particular group
[18:44] <lifeless> cr3: the hwdb is still referencing things by their current url
[18:45] <lifeless> cr3: the current url might be defined in an immutable fashion, but its still 'current url'
[18:45] <cr3> lifeless: could the enterprise-wide person reference be the database sequential id in lp or are we thinking of something wider than that?
[18:46] <lifeless> cr3: I don't think it can, no. Person ids get merged.
[18:46]  * cr3 will probably have to research how others have solved this problem before
[18:47] <cr3> lifeless: just for my edification, when do person ids get merged?
[18:47] <lifeless> or rather, it may be we can use the row key, but we need a way to handle lookups on persons that have been merged
[18:47] <lifeless> cr3: 'claim my account'
[18:47] <lifeless> cr3: or 'this person is me'
[18:48] <cr3> lifeless: ok, solving this problem will probably be useful for me in other contexts too, like when merging similar systems for ubuntu friendly
[18:49] <cr3> lifeless: do you know if this problem has been tackled before within canonical? any leads you know I should be following to start my exploration down this person access service?
[18:49] <cr3> lifeless: also, should we create a bug as you suggested before, or something else, to keep track that someone is looking into this?
[18:52] <lifeless> so, I think you need to look at how you use the mirrored person metadata
[18:53] <lifeless> and you need to make a bug / LEP that says 'results tracker needs real-time access to <foo> for <bar>' (repeat items in the bug/lep for batch vs single vs search)
[18:53] <lifeless> then we can think about how best to expose that and things that will cause trouble.
[18:56] <cr3> lifeless: sounds like a plan. I'm not entierely clear but it certainly gives me something to do and bounce later for feedback.
[18:56] <lifeless> cool
[18:57] <cr3> I need to jet for now, thanks for the guidance!
[18:57] <lifeless> to help clarity: look at your mirrored metadata; look at where you use it (queries, batches, individual templates) and write up a list so that we can together figure out how to meet those uses without you mirroring [all] of the data.
[18:57] <lifeless> bwah
[20:13] <lifeless> has anyone around atm setup a local oops-tools instance before?
[20:22] <jelmer> no
[20:43] <jelmer> also, g'morning :-)
[20:45] <lifeless> hi :)
[20:47] <nigelb> evening jelmer :)
[20:57] <jelmer> hey Nigel, what are you hacking on?
[20:57] <nigelb> jelmer: Nothing much tonight :)
[20:58] <nigelb> Need to do some stuff over the week.
[21:02] <lifeless> hmm
[21:02] <lifeless> I wants rabbitmqadmin packaged :)
[21:03] <lifeless> ah , it is
[22:30] <lifeless> where is that hack to change the command line ?
[22:30] <lifeless> (to hide passwords etc)
[22:34] <mwhudson> setproctitle?
[22:35] <lifeless> ah thanks
[22:35] <lifeless> I suspect I won't use it here (anyone with access to the same machine has access to the prod configs...)
[22:36] <lifeless> but its nice to remember it exists
[22:36] <lifeless> also
[22:36] <lifeless> amqp for oops-tools. Done.
[22:36] <lifeless> \o/
[22:36] <mwhudson> i don't know if using that for security is valid btw, there might be some way of digging out the original command line
[22:36] <lifeless> mwhudson: + race conditions
[22:36] <lifeless> python takes a while to start up after all
[22:36] <mwhudson> yeah, that too
[22:37] <lifeless> did I mention amqp ?
[22:37] <lifeless> :P
[22:37] <mwhudson> yes, that sounds very nice :)
[22:37] <lifeless> https://code.launchpad.net/~lifeless/python-oops-tools/amqp/+merge/79505
[22:52] <lifeless> (diff is there now)
[23:04] <lifeless> righto and local setup working. \o/
[23:21] <wgrant> lifeless: lucid?
[23:32] <lifeless> wgrant: of course
[23:39] <lifeless> anyone else seeing "Launchpad encountered an internal error during the following operation: generating an incremental diff for a merge proposal.  It was logged with id OOPS-2115MPJ4.  Sorry for the inconvenience"
[23:39] <lifeless> I thought we had incrementals turned off ?
[23:44] <wgrant> They're not displayed.
[23:44] <wgrant> But I think they're still generated.
[23:44] <wgrant> And yes, we've had a couple of reports of that last week.
[23:54] <lifeless> win ec2
[23:55] <lifeless> ec2test@i-da2526ba$ cd /var/launchpad/test; bzr merge lp:~lifeless/launchpad/useoops
[23:55] <lifeless> ssh: connect to host ec2-50-17-126-253.compute-1.amazonaws.com port 22: Connection timed out