On 18 May 2011 21:03, Robert Collins wrote:
> Sure. I think we may have /some/ apis we choose to expose externally, but the
> default is internal. And this isn't a question of openness: the control
> protocol for the blob-store for Launchpad is only relevant to LP servers &
> scripts. []
On Thu, May 19, 2011 at 5:46 AM, Martin Pool wrote:
> On 17 May 2011 22:42, Robert Collins wrote:
>
> You're probably right to split the internal from the external API.
> Much as I'd like to see the external one improved, you are right that
> the internal one is more important right now.
>
> But
On Thu, May 19, 2011 at 6:58 AM, Aaron Bentley wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11-05-18 02:38 PM, Robert Collins wrote:
>> On Thu, May 19, 2011 at 1:18 AM, Aaron Bentley wrote:
>>> But it would be an awesome one to change, because it would allow us to
>>> spin up i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11-05-18 02:38 PM, Robert Collins wrote:
> On Thu, May 19, 2011 at 1:18 AM, Aaron Bentley wrote:
>> But it would be an awesome one to change, because it would allow us to
>> spin up instances of Launchpad at will. That would allow us to QA our
>>
On Thu, May 19, 2011 at 12:18 AM, Jamu Kakar wrote:
>> 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 loa
On Thu, May 19, 2011 at 1:18 AM, Aaron Bentley wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11-05-17 11:02 PM, Robert Collins wrote:
>
>> I think that that will come naturally; as far as vms vs puppet, I'm
>> inclined to stick with the current toolchain IS are using - its a
>> v
On 17 May 2011 22:42, Robert Collins wrote:
You're probably right to split the internal from the external API.
Much as I'd like to see the external one improved, you are right that
the internal one is more important right now.
But I can't quite get away from thinking about how they ought to rela
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11-05-17 11:02 PM, Robert Collins wrote:
> I think that that will come naturally; as far as vms vs puppet, I'm
> inclined to stick with the current toolchain IS are using - its a
> variable we don't need to change.
But it would be an awesome one t
Hi,
First of all, thanks for writing the document in the wiki and pushing
this discussion forward. It's very exciting and I'm looking forward
to see how this proposal evolves and gets put into practice.
On Wed, May 18, 2011 at 5:53 AM, Michael Hudson-Doyle
wrote:
> On Wed, 18 May 2011 15:02:45
On Wed, May 18, 2011 at 7:31 PM, Ian Booth wrote:
> Thinking out loud, would it be feasible to still use the zope component
> model (eg interfaces) to define the services' APIs - they could be
> easily run up outside the container for unit testing but when run inside
> zope, we would still get the
>>
>> 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
On Wed, May 18, 2011 at 3:53 PM, Michael Hudson-Doyle
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
On Wed, 18 May 2011 15:02:45 +1200, Robert Collins
wrote:
> > I think an advantage that we'll gain from all this is greater fault
> > tolerance. Because we'll have more services to fail, they will fail
> > more often, and if we don't get better at this we'll present a really
> > terrible user ex
I would like to say thank you to both Robert and the entire Launchpad
development community, from architect all the way to beta testers and
bug reporters for the fantastic progress made so far.
On Mon, May 16, 2011 at 11:01 PM, Robert Collins
wrote:
> https://dev.launchpad.net/ArchitectureGuide/S
On Wed, May 18, 2011 at 2:08 PM, Michael Hudson-Doyle
wrote:
> Hi all,
>
> This seems like a really exciting proposal. It describes a world
> significantly more awesome than the current one, and inspires the
> following slightly incoherent thoughts.
Thanks for sharing them...
> Part of this pro
Hi all,
This seems like a really exciting proposal. It describes a world
significantly more awesome than the current one, and inspires the
following slightly incoherent thoughts.
Part of this proposal seems to be saying "by taking away something we're
good at, we'll force ourselves to get bette
On Tue, May 17, 2011 at 11:08 PM, Martin Pool wrote:
> Those are awesome results. I also really admire the way you keep on
> so consistently celebrating the progress and pointing the way forward.
Thanks! Details interleaved below...
> Some thoughts, not all linked up or fully cooked:
>
> * I'm
Those are awesome results. I also really admire the way you keep on
so consistently celebrating the progress and pointing the way forward.
> https://dev.launchpad.net/ArchitectureGuide/ServicesAnalysis
>
> Please read this and do one of:
> - comment in it
> - reply to this thread
> - reply to
On Tue, May 17, 2011 at 3:01 PM, Robert Collins
wrote:
> I've spoken to some of you already about this - thank you -very- much
> for your feedback on the proposal so far. I owe you all! The list at
> the top of the document is probably not complete - some of the ideas
> have been around (literally
19 matches
Mail list logo
