launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Wed, May 18, 2011 at 3:53 PM, Michael Hudson-Doyle
<michael.hudson@xxxxxxxxxxxxx> 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