Age | Commit message (Collapse) | Author |
|
In a multi-node couch deployment, it was observed that the Service['stunnel']
would be activated, and then later a stunnel::client was created which would
trigger an Exec['refresh_stunnel']. Because of this, and the ordering hints
that were in place, the service would get started, and then the couchdb
databases, users, designs, etc. were being put into place and then a stunnel
client was created, triggering the refresh_stunnel exec, which would cause
an interruption in the connectivity and result in failures.
This change replaces the Service['stunnel'] hint with the the
Exec['refresh_stunnel'] to make sure that the stunnels are fully setup before
attempting couch operations.
Change-Id: I33ddd24884b3c23a1df5555ca53ca65cd703da50
|
|
|
|
|
|
out into separate files.
|
|
|
|
|
|
class to be more visually logical (#5269, #4590, #3712)
Change-Id: I58c28c3bc62e67b25f33da3378e8146110471613
|
|
. make the couchdb service start after the stunnels have been
setup. This may improve the cluster membership coming online
faster
. replace the two Couchdb::Create_db ordering hints (for the
'users' and 'tokens' databases) with a generic
Class['site_config::create_dbs'] hint. This makes it so we get
the ordering hint for all databases, which we were not before,
without having to individually list them
. replace the two Couchdb::Add_user ordering hints (for the
$couchdb_webapp_user and the $couchdb_soledad_user) with a
generic ordering hint for Class['site_couchdb::add_users']
ordering hint. This makes it so we get the ordering hint for all
the users, which we were not before, without having to
individually list them
Change-Id: Ia63e62d68d24e77a49d4ef928a2a8130ab7bccb9
|
|
cluster membership to settle, before attempting any operations
(#5269, #4590, #3712)
Change-Id: Ic9826dda1c242e705ce85ae218766496bdd8ecbd
|
|
|
|
|
|
|
|
local checks
|
|
|
|
|
|
|
|
|
|
Change-Id: Ic0e9f5f6a1f28d865d7757a9de0d9399a6a9a5e3
Conflicts:
puppet/modules/site_couchdb/manifests/init.pp
|
|
Change-Id: I77061054f4768f0677ca9c498e6cd6d5df4ff806
|
|
Change-Id: I41e9a73c8d04d5a2d74b41c8e32aca9906f3a4cf
|
|
Change-Id: Ice83115e0feabddd40ad74c2a6e98e24da9b4c2f
|
|
alphabetizing couchdb users
Change-Id: I88264d32e9381f826652d1631083ba371e2b1b54
|
|
into different classes
Change-Id: Idd126d69e1fbe9c9794ad50337307dcc5dd635f4
|
|
Change-Id: Ib9525c3a933041fa9b378e1869c0a866375bb509
|
|
|
|
( they can read and write ). I think couch themselves changed the termology at some point but i might just have used the wrong term from the beginning on.
Let's call them members either way because it's more clear that read only members require aditional design docs.
|
|
shorewall is setup before the service is setup. This is necessary due to the strict initial firewall that stops various service setup operations from happening, but is relaxed once shorewall is setup properly (#3782)
Change-Id: Ia9640c4118aa0053cdb99e7bc11860fed5527501
|
|
* fix stunnel setups for couchdb, mx, webapp services
|
|
|
|
|
|
Change-Id: Ia35cf7a9fc1d0fad6a57bbae73968ab6b8f0c847
|
|
made to create databases or add users as these would fail otherwise. Closes: #3466
Change-Id: Ifa8b3da5858ce858fd319c4a659e70d20a65d3e0
|
|
|
|
|
|
|
|
|
|
|
|
setup ednp_server and ednp_client stunnels
update couchdb puppet submodule to support configurable ednp_port parameter and general module cleanup
pass ednp_port to couchdb setup so that it is configured in the vm.args template
clarify in comments the difference between the epmd and ednp ports
remove hard-coded erlang_vm_port variable and instead setup shorewall to allow for the stunnel connection only
setup dnat rules for the ednp client connections
|
|
|
|
|
|
|
|
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?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|