Introduce ICINGADB_SLEEP=30 #27
Conversation
Blocked by |
There was a problem hiding this comment.
When this needs explicit configuration anyways, why not make it a flag that enables or disables automatic schema upgrades altogether? Then it'd also be safe even if they start with unfortunate timing. Could also be something like "check schema version, if it doesn't match, wait some time for it to be applied", so that this wouldn't delay every start.
|
Because then the other instance just crashes. (Icinga/icingadb#295) |
|
Not if you wait for the schema to be upgraded by the other instance. You have to coordinate upgrades between all instances anyways, you don't want one instance running while the other is upgrading the schema. I'd still argue for not doing automatic schema upgrades for now. We don't really need it for now (if you use a pre-release version, it's totally acceptable if you have to apply schema migrations yourself) and after we released 1.0, we want to be careful about what schema changes we do anyways as we don't want to break compatibility everywhere all the time. So I'd say it makes much more sense to think about and implement automatic schema upgrades, once we actually have the need for it for production setups and also know the types of schema changes we want to make. |
No description provided.