launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Thu, May 19, 2011 at 1:18 AM, Aaron Bentley <aaron@xxxxxxxxxxxxx> 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
>> variable we don't need to change.
>
> 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
> work immediately after it hits (db-)devel.

I don't see how it permits that any more efficiently than we do today
- we already spin up new code in < 30 minutes after it hits trunk. The
bulk of the delay is in code updates. We can't just spin up some vms
and solve the problem because we're dealing with constraints like a
300GB DB that takes a day to restore.

>>> We do have an example that's similar in many ways to what you describe
>>> in LP today: codehosting.
>
> Another example is the buildd, which we've been wanting to split out.

Exactly, yes.

>> Each of those get_ things was a thread-dispatched sync backend request
>> using $protocol and returning loosely structured data - perhaps mapped
>> to model objects, or perhaps just basic types. Any mapping to model
>> objects would be done in the template server.
>
> ISTM that the service providing the data will also need to have model
> objects (for data sanity, etc).  Have you thought about what
> relationship the template-side model object would have to the
> service-side model object?

I think there are a few interesting influences here. On one hand the
lazr.restful API requires us to have an identical data model to what
we have today be available. On the other hand as mwhudson says doing
just data objects or even dicts is quite appealing for maximum
flexibility on the template side. We do occasionally use the ability
to do interesting adaption logic to get different templates for the
same object, so losing that would require some new answers - and
irrespective of whats best, I think its important to be able to stage
how we get there - to reduce the risk we take on at any point in time.

I suspect that in the short term we need a 1:1 mapping for the API,
but the behaviours of the model objects would not be duplicated to the
template service, only the surface -  what attributes exist. Methods
for the API we would want to explicitly map I think.

I realise this is more of a handwave for now :(

-Rob