| === Spads_ is now known as Spads | ||
| === Spads_ is now known as Spads | ||
| === Spads_ is now known as Spads | ||
| cjwatson | mapreri: Done. | 09:12 |
|---|---|---|
| free | cjwatson: hey there, around? I'd have a question about scalability off PPAs (I think you already talk about that with Adam Collard, so I just want to make sure I have all facts) | 10:45 |
| cjwatson | free: Ask away | 11:27 |
| free | cjwatson: I know it was mentioned that for private PPAs there is a known scalability issue around fs contention of .htaccess | 11:28 |
| free | cjwatson: I'd like to know there are any known issues of plain PPAs (or possibly a private PPAs whose authentication is proxied but some external frontend, so the private PPAs would just get a bunch of requests from one user/pw, even tho that's multiplexed transparently by the proxy) | 11:29 |
| cjwatson | free: Well, they're hosted on a single server, so there's that. | 11:31 |
| cjwatson | free: If you're expecting to deploy sources.list entries for a PPA to $LOTS of users, it's probably wise to mirror it somewhere that you can scale up | 11:32 |
| free | cjwatson: ah well, that has a flip side. If you mean that *all* ppas in LP are hosted by a single server (apache serving static files I guess), that alone is probably a proof that it scales to a size that is already reasonable to us | 11:33 |
| cjwatson | free: Apache static, yes. It's mostly OK, although we do occasionally hit problems when say the big libreoffice PPA updates and flatlines our network | 11:34 |
| cjwatson | free: Generally as far as downloads from public PPAs are concerned we saturate the network first | 11:34 |
| free | cjwatson: okay, it sounds like it'd be good enough for a start, and we could take measure only if we do see issues | 11:34 |
| cjwatson | free: Private PPAs will have TLS overhead, but that's probably not too awful these days | 11:35 |
| free | cjwatson: that's good, it probably means it would be conceivable to put more servers (perhaps backed by some sort of network fs) | 11:35 |
| cjwatson | free: We have plans for that, although not with a networked filesystem | 11:35 |
| free | cjwatson: I was wondering if you'd be interested to get a couple of Landscape folks work or helping solving the .htaccess issue with Private PPAs (essentially moving the lookup to the db). If it makes sense. | 11:36 |
| cjwatson | free: (probably at least a year out though realistically - the design is only at the block-diagram level) | 11:37 |
| free | cjwatson: yeah, I don't think it will be a problem in that time frame, realistically (and perhaps not even later) | 11:37 |
| cjwatson | free: Possibly, yes. I think what we'd want in terms of infrastructure would be a WSGI thing that can plug into Apache at the authnz level. | 11:37 |
| free | cjwatson: right, sounds good | 11:38 |
| free | cjwatson: okay, we'll reason about that, but from the outlook I'd expect that we'd want to come back to make that concrete, as the alternative of proxying the private PPAs seems a hack and waste of work | 11:38 |
| cjwatson | I agree. | 11:39 |
| cjwatson | It's definitely something we'd like to fix in a way that isn't terrible. | 11:39 |
| cjwatson | I think when I last looked it didn't seem terribly easy to hook a WSGI thing in at the right layer, but I don't remember very clearly and besides I might have missed something. | 11:40 |
| cjwatson | We'd obviously then also need to make sure that the actual authorizer implementation is doing a very fast query. | 11:40 |
| free | cjwatson: I'm not sure of the details, but seems they could be worked out. Worst case bypassing WSGI | 11:41 |
| cjwatson | But that should be easy by comparison. | 11:41 |
| free | cjwatson: right, it'd need benchmarks | 11:41 |
| cjwatson | Well, EXPLAIN ANALYZE anyway | 11:41 |
| ackk | cjwatson, any specific reason you'd want WSGI rather than mod_authn_dbd? | 11:43 |
| cjwatson | ackk: Would strongly prefer to have it talking directly to our database in the usual way (i.e. with Storm) rather than having to do it through an entirely separate codebase. This means that e.g. we get all our usual oops infrastructure when things go wrong, we have caching, quoting, etc. behaviour that we're used to, and so on. | 11:46 |
| ackk | cjwatson, I see | 11:46 |
| cjwatson | https://modwsgi.readthedocs.io/en/develop/user-guides/access-control-mechanisms.html is a thing, so it's probably doable with WSGI. | 11:48 |
| === acheronuk is now known as acheronuk_ | ||
| === acheronuk_ is now known as acheronuk | ||
| tumbleweed | what does it mean when a build fails without a log? https://launchpad.net/~stefanor/+archive/ubuntu/pypy/+build/9897779 | 18:02 |
| dobey | tumbleweed: crashed before logs were created or similar types of errors. a retry should work | 18:10 |
| * tumbleweed does so | 18:12 | |
| === Spads_ is now known as Spads | ||
| === Spads_ is now known as Spads | ||
| lazyPower | I have a project that was self-registered by the contributors of the charm, is there any chance we can 'administratively add' charmers as an admin of this group? https://launchpad.net/~midonet-charmers | 19:44 |
| dobey | lazyPower: i think not really (the owner could just remove the team if it was forcibly added). seems like you should discuss that with that team's owner instead of trying to use admin force to accomplish it | 19:49 |
| lazyPower | ah good point. Will go that route | 19:50 |
| lifeless | rbasak: thanks | 20:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!