On Wed, May 18, 2011 at 3:53 PM, Michael Hudson-Doyle <michael.hud...@canonical.com> wrote: >> :) Thats certainly a component, but your math is flawed; the absolute >> number of appservers may not change - we may just shuffle. The failure >> rates for each service may be different. The backend services will all >> be haproxied or similar. So I don't think its as simple as 'more >> components - more failures to deal with'. Possible more /sorts of >> failures/ - thats something that I think needs attention; but not >> failures-per-day. > > I think I mostly meant more kinds of failures.
Righto - so yes, thats a real concern, but one I think is already documented. > Sure, puppet is a totally adequate solution here (this actually occurred > to me over lunch). I guess the actual point is that we want operations > like "adding another server to the haproxy pool for service $foo" and > "setting up a service built of standard components (e.g. http served by > haproxy/python/postgres)" to require little time and even less thinking > from the sysadmins -- including setting up things like nagios and > logging. Yes indeed; this has been an ongoing theme in the ops aspects of Launchpad for a while now, and I expect that this project will increase the visible importance of that. ...enerally, RPC I guess) API that's important, and the protocol is a >> > detail. I also don't know of a protocol that has what I would consider >> > good error handling built into it though. >> >> I agree with all of this. > > Another point that occurred after lunch: for all sorts of reasons, > accessing a remote service should be explicit in our code (so let's not > use xmlrpclib.ServerProxy?). I'm sure you know this in your bones by > now with all the lazy loading Storm pain :) Implementing everything in > Twisted and so having deferreds bubble around would acheive this, but is > probably massive overkill! I think some services would want to be in twisted or tornado or what have you; I think for sanity and compatibility with our massive investment in WADL + lazr.restful it would be very high risk to make the front end twisted at the core. >> > For more concrete comments on the document, there are two sentences that >> > I just plain don't understand: ... > I've adjusted both explanations in the wiki. Thank you! >> > In the section "Identified service opportunities" I think it would be >> > good to explain a bit more what the services described actually do. >> >> We may want to move them to separate documents or even LEPs. Some of >> them are getting pretty concrete. > > Well sure, but the first paragraph under "team participation / directory > service" doesn't appear connected to anything else in the document. > Perhaps just reversing the order of the paragraphs in this section would > be a good start :) I'll have a fiddle there now. ... > I think this all makes some sort of sense. Two further thoughts spring > from this: > > If there is a traversal service, it would map URLs to ... what? Do > things that are model objects today all have some kind of unique name in > the new world (it could be as simple as bug-$id)? I guess it could > return just a (view-name, model-object-name) pair. I think there is a need for site wide unique ids for objects; possibly as simple as (class, id) - but there are folk with more experience than I that will surely inform this discussion (/me looks at wallyworld). > The other thought is that I'm not sure the concept of a model object is > useful in this new world! I think I'd favour returning loosely > structured data from the service (roughly the set of data types JSON > supports... although probably one would want some others, such as > dates) sounds about right to me. I guess one won't know until something > gets implemented. me too. -Rob _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
