"
Note that Andrew has already started work on allowing us to run multiple
Conch processes (and associated forking processes), so that we can
handle no-downtime deployments anyway. Which also helps us with high
availability, etc."
what does this mean? I wouldn't want to run > 1 conch per forking
service, or vice versa. If hes simply talking about having multiple
conch processes with an haproxy front end, we're already ready to do
that; the thing that andrew was working on for a status page is about
graceful handoffs when doing nodowntime deploys (and thats pretty
important in the long-running connection model of bzr).
"
Note that Andrew has already started work on allowing us to run multiple
Conch processes (and associated forking processes), so that we can
handle no-downtime deployments anyway. Which also helps us with high
availability, etc."
what does this mean? I wouldn't want to run > 1 conch per forking
service, or vice versa. If hes simply talking about having multiple
conch processes with an haproxy front end, we're already ready to do
that; the thing that andrew was working on for a status page is about
graceful handoffs when doing nodowntime deploys (and thats pretty
important in the long-running connection model of bzr).
-Rob