Add PostgreSQL primary support to the kosmos-ejabberd cookbook #181
No reviewers
Labels
No Label
service
accounts
service
discourse
service
drone-ci
service
email
service
garage
service
gitea
service
ipfs
service
mastodon
service
postgres
service
remotestorage
service
wiki
service
xmpp
bug
design
dev environment
docs
duplicate
enhancement
feature
good first issue
idea
invalid
kredits-1
kredits-2
kredits-3
on hold
ops
question
release
major
release
minor
release
patch
security
ui/ux
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: kosmos/chef#181
Loading…
Reference in New Issue
No description provided.
Delete Branch "feature/180-ejabberd_pg_primary"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
pg_db
recipepg_db
recipeRefs #180
I find it rather complicated that we should specifically allow PostgreSQL access per app and database, instead of allowing our own servers to connect to the primary by default. Why wouldn't a replica be allowed to connect to the primary just because it's a replica? It does that for replication anyway, and thus should needs access to all databases in the first place.
The fact that configuring simple database access requires an entire recipe should ring some alarm bells in my opinion.
Replication is a special right, this is defined here for replicas:
81403b7cb9/site-cookbooks/kosmos-postgresql/recipes/default.rb (L48-L55)
.A server connecting to the PostgreSQL primary as a client is not necessarily a replica, but as you said it could be done for all databases at once. I had the idea of definining each database as we need a recipe anyway to create the postgreSQL user and database for each service. Allowing access to all databases for a server could be done as part of the primary recipe, however it means the list of all services that use PostgreSQL would live there instead of the recipe for the service. I'm not opposed to doing that, I just thought doing it per database was clearer.
I didn't mean replication per se, but all Hetzner machines would definitely be replicas for now anyway.
I mean that any of our Hetzner machines should be able to connect to the Posgtgres server in the first place. The actual authentication is then the username/password for the database, and doesn't require whitelisting the host per database.
I'm going to look into it, there has to be a way that looks good in Chef code. Not having to run Chef again on the primary every time we add a new service will be useful
It's not about looking good, it's about adding unnecessary complexities and code.
Pushed
6f696d7
, what do you think?At least it's half the LOC. Looks much better to me.
However, I don't quite understand why it still has to be searching for every single app. Isn't there an easier way to know that a machine has roles/attributes that require postgres access? If it's not bound to the application, then it can never be out of sync.
I have found a better way. See
ee9c241a4d
, I have added apostgresql_client
roleLGTM now. 👍