maas-devel team mailing list archive

[Gavin Panella <gavin.panella@xxxxxxxxxxxxx>]

On 8 May 2012 19:38, Robert Collins <...> wrote:
> In addition to Clint's excellent points (all of which I agree with),
> I'd also add two more points:
>
> * pserv, being twisted, means that it will have a hate-hate
> relationship with ORM state, just keeping it from doing silly things
> like keeping a transaction open for days will be an exercise in
> great care and diligence.

PostgreSQL can enforce transaction and/or query time-outs, can't it?
If not, then Twisted has callLater.

>
> * all the protections we (eventually) put in place around the DB
> (such as timeouts and worker concurrency limits) will have to be
> replicated for pserv, and as it has a different programming model,
> that means double work. In LP we haven't done this yet, and we have
> had the failure modes (like a script that goes nutty keeping backps
> from running, or a concurrent script causing unanticipated load) at
> one time or another. MAAS, being deployed on customer sites, outside
> of our ops teams reach, has to insulate itself from these sorts of
> things.

We used Storm and transactions and all that stuff with ease and
without incident in clouddeck with no special provisions for Twisted
other than: do transactional stuff in a thread that is not the reactor
thread [1].

I'm almost certain that it would be trivial to use Django's ORM within
Twisted too.


[1] Or: *never ever ever never ever* do transactions in the reactor
thread. Partly because, iirc, the transaction module expects to be
able to use thread-locals to keep track of transaction state, hence
doing all transactions in a single thread leads us right into the
belly of the beast.