| === Nigel_ is now known as G | ||
| === jkakar_ is now known as jkakar | ||
| === micahg_ is now known as micahg | ||
| lifeless | cr3: ol | 18:20 |
|---|---|---|
| lifeless | ola | 18:20 |
| nigelb | Morning lifeless :) | 18:21 |
| nigelb | Damn, its still yesterday for me. | 18:21 |
| 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:23 |
| 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:24 |
| cr3 | lifeless: my understanding is that the next step consisting of auditing the code, does that sound about right? | 18:26 |
| 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:28 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| cr3 | lifeless: anyways, we'll burn that templates bridge when we're on it, lets concentrate on the person access service for now :) | 18:43 |
| 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:44 |
| 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:45 |
| 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:46 | |
| 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:47 |
| 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:48 |
| 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:49 |
| lifeless | so, I think you need to look at how you use the mirrored person metadata | 18:52 |
| 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:53 |
| 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:56 |
| 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 | 18:57 |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| === jtr is now known as jtr__ | ||
| lifeless | has anyone around atm setup a local oops-tools instance before? | 20:13 |
| jelmer | no | 20:22 |
| jelmer | also, g'morning :-) | 20:43 |
| lifeless | hi :) | 20:45 |
| nigelb | evening jelmer :) | 20:47 |
| jelmer | hey Nigel, what are you hacking on? | 20:57 |
| nigelb | jelmer: Nothing much tonight :) | 20:57 |
| nigelb | Need to do some stuff over the week. | 20:58 |
| lifeless | hmm | 21:02 |
| lifeless | I wants rabbitmqadmin packaged :) | 21:02 |
| lifeless | ah , it is | 21:03 |
| lifeless | where is that hack to change the command line ? | 22:30 |
| lifeless | (to hide passwords etc) | 22:30 |
| mwhudson | setproctitle? | 22:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| lifeless | (diff is there now) | 22:52 |
| lifeless | righto and local setup working. \o/ | 23:04 |
| wgrant | lifeless: lucid? | 23:21 |
| lifeless | wgrant: of course | 23:32 |
| 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:39 |
| 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:44 |
| lifeless | win ec2 | 23:54 |
| 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 | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!