Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
if we move, then we need to re-create the file on the next deploy
|
|
privileges, putting the unprivileged ones in as user webapp in couchdb.yml. This allows us to migrate the couchdb design docs on deployment, but use an unprivileged user the remainder of the time
|
|
|
|
|
|
|
|
haproxy listener 'bigcouch-in'. This haproxy listener is configured to listen on
port 4096 (arbitrarily chosen) and balance across the locally configured
stunnels to the bigcouch instances
It may be that we will need some additional haproxy options for handling
persistence, cookies, or other HTTP headers, I'm unsure as of this moment
|
|
|
|
|
|
|
|
|
|
|
|
|
|
rate limited).
|
|
|
|
Until we have a proper load balancing setup
(see https://leap.se/code/issues/1994)
|
|
|
|
|
|
|
|
|
|
|
|
all stunnel client/servers will need handled (at least in debian and ubuntu)
|
|
This presents us with an interesting problem of deprecation. We need to manage
the removal of something that we previously installed in any released code. How
long we carry the puppet code that removes raises some interesting questions: do
we require that someone who deployed version 1 (where the apache ssl proxy was
deployed) of the platform upgrade first to version 2 (where we remove the apache
ssl proxy) before they upgrade to version 3 (where the apache ssl proxy removal
is no longer present) -- or do we allow people to skip versions?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|