launchpad-dev team mailing list archive

[Guilherme Salgado <salgado@xxxxxxxxxxxxx>]

On Wed, 2010-01-06 at 10:53 +0000, Gavin Panella wrote:
> On Wed, 06 Jan 2010 10:22:09 +0000
> Tom Haddon <tom.haddon@xxxxxxxxxxxxx> wrote:
> 
> > On Wed, 2010-01-06 at 10:46 +0700, Stuart Bishop wrote:
> > > On Wed, Jan 6, 2010 at 10:30 AM, Martin Pool <mbp@xxxxxxxxxxxxx> wrote:
> > > 
> > > > Perhaps a similar method could be used in future for site-wide
> > > > notifications.  <https://dev.launchpad.net/NotificationSystem>.  For
> > > > example if there is a site-wide-notification.txt, it can contain
> > > > configuration for a message to be displayed in a banner at the top of
> > > > some or all html pages.
> > > 
> > > I'd rather pull this information from the database or even ajax load
> > > it from a static URL. Coordinating the .txt files over all the
> > > different appserver trees is a pain we should avoid when possible.
> > 
> > Er, which database? Wouldn't that make the whole "read-only" thing a
> > little more problematic (i.e. how do you switch out of read-only when
> > you're checking a DB that's not writable)?
> > 
> 
> If the DB is not writable, I think you shouldn't be switching out of
> read-only mode on the app servers. That sounds like it will break.
> 
> How about the following approach, instead of read-only.txt files?
> 
>  * For each request, check for a flag/setting in the db that says
>    read-only. This means we can put the DB in a soft read-only state,
>    where existing requests can complete, but new requests will be
>    read-only.

I think this doesn't work for us because during a roll out we may want
some app servers (e.g. lpnet*) to go into read-only mode while others
stay in read-write (e.g. login.lp.net).

At some point login.lp.net will go to ISD's hands (as well as the auth
database), but until then I don't think we can go store the
read-only/write flag in the DB without some significant refactoring in
the infrastructure shared by both lp.net and login.lp.net.


-- 
Guilherme Salgado <salgado@xxxxxxxxxxxxx>

Attachment: signature.asc
Description: This is a digitally signed message part