=== Nigel_ is now known as G === jkakar_ is now known as jkakar === micahg_ is now known as micahg [18:20] cr3: ol [18:20] ola [18:21] Morning lifeless :) [18:21] Damn, its still yesterday for me. [18:23] it always will be [18:23] nigelb: hey, hows the jsoopsd going ? [18:23] lifeless: Haven't started yet. Life. [18:23] :) [18:23] lifeless: hola senor! [18:24] cr3: I'm wondering how to get the service integration for the results tracker underway [18:24] cr3: like e.g. should we identify a couple of useful steps and create bugs for the, ? [18:24] s/the,/them/ [18:26] lifeless: my understanding is that the next step consisting of auditing the code, does that sound about right? [18:28] 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] :) [18:31] so the code review was part of being willing to open backend ports betwee it and LP [18:31] we kindof need to do that & the first backend service at the same time [18:32] lifeless: what do you mean by "first backend service"? [18:32] service call [18:32] thing where it calls into LP via a trusted API [18:32] e.g. direct person access [18:33] lifeless: ok, does LP already have direct person access? [18:33] currently the only APIs for person at the launchpadlib ones - which means you'll run into trouble if the account is renamed [18:33] lifeless: btw, opening backend port can be done as one step and then actually using that port a second step [18:34] 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] lifeless: do you envision the person access needing a microservice of its own? how will that work? [18:35] long term we might do a dedicated directory service, yes. [18:35] medium term LP is the directory, so I'd expect targeted APIs on its services [18:35] lifeless: short term, database access? privileges launchpadlib api? [18:35] 9 [18:35] bah [18:35] no, no db access, ever ever ever ever evcer [18:35] good, I was going to whine otherwise :) [18:35] possibly a privileged lplib API, or an xmlrpc api [18:36] 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] cr3: thats a good goal, but there are two very distinct paths to it [18:37] cr3: one path is to say 'run up as much of LP, *or equivalent services*, as the tracker needs' [18:37] cr3: the other path is to say 'the tracker knows how to run standalone and how to run integrated' [18:37] 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] 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] lifeless: I was leaning towards the latter: being able to parameterize whether the tracker is running integrated or standalone [18:39] 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] 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] 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] lifeless: maybe a tracker aware zope component that points to templates in the tracker codebase, I really don't know [18:42] cr3: That sounds awfully complex vs saying 'templates are in the LP tree' [18:42] lifeless: to me, "LP tree" means it can't run standalone [18:43] lifeless: anyways, we'll burn that templates bridge when we're on it, lets concentrate on the person access service for now :) [18:44] 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] (or reduce it to non-duplicated data [e.g. an enterprise-wide person reference] [18:44] 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] cr3: the hwdb is still referencing things by their current url [18:45] cr3: the current url might be defined in an immutable fashion, but its still 'current url' [18:45] 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] 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] lifeless: just for my edification, when do person ids get merged? [18:47] 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] cr3: 'claim my account' [18:47] cr3: or 'this person is me' [18:48] 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] 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] 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] so, I think you need to look at how you use the mirrored person metadata [18:53] and you need to make a bug / LEP that says 'results tracker needs real-time access to for ' (repeat items in the bug/lep for batch vs single vs search) [18:53] then we can think about how best to expose that and things that will cause trouble. [18:56] 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] cool [18:57] I need to jet for now, thanks for the guidance! [18:57] 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] bwah === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === jtr is now known as jtr__ [20:13] has anyone around atm setup a local oops-tools instance before? [20:22] no [20:43] also, g'morning :-) [20:45] hi :) [20:47] evening jelmer :) [20:57] hey Nigel, what are you hacking on? [20:57] jelmer: Nothing much tonight :) [20:58] Need to do some stuff over the week. [21:02] hmm [21:02] I wants rabbitmqadmin packaged :) [21:03] ah , it is [22:30] where is that hack to change the command line ? [22:30] (to hide passwords etc) [22:34] setproctitle? [22:35] ah thanks [22:35] I suspect I won't use it here (anyone with access to the same machine has access to the prod configs...) [22:36] but its nice to remember it exists [22:36] also [22:36] amqp for oops-tools. Done. [22:36] \o/ [22:36] 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] mwhudson: + race conditions [22:36] python takes a while to start up after all [22:36] yeah, that too [22:37] did I mention amqp ? [22:37] :P [22:37] yes, that sounds very nice :) [22:37] https://code.launchpad.net/~lifeless/python-oops-tools/amqp/+merge/79505 [22:52] (diff is there now) [23:04] righto and local setup working. \o/ [23:21] lifeless: lucid? [23:32] wgrant: of course [23:39] 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] I thought we had incrementals turned off ? [23:44] They're not displayed. [23:44] But I think they're still generated. [23:44] And yes, we've had a couple of reports of that last week. [23:54] win ec2 [23:55] ec2test@i-da2526ba$ cd /var/launchpad/test; bzr merge lp:~lifeless/launchpad/useoops [23:55] ssh: connect to host ec2-50-17-126-253.compute-1.amazonaws.com port 22: Connection timed out