If multiple Krill instances use the same shared data store (PostgreSQL), they should all run the same version of Krill - or bad things can and probably will happen.
The best way to prevent issues in this scenario would be to:
stop all Krill instances
make a backup of the data
upgrade one node
start it and let it do the migration
then upgrade other nodes
However, we cannot be sure that operators will always do this.
So, it would be very useful to modify or extend the PropertiesManager to support the notion of not just the current Krill version, but also of any upgrades that may be in progress.
We can then use to do the following:
prevent multiple concurrent upgrades
let Krill monitor the current version and exit if it is behind the data (in case people forget to stop all nodes).
let Krill refuse to start if it is behind
possibly.. define behind in this context as a version difference that implies a breaking change (e.g. 0.14.0 -> 0.14.1 would be okay, but 0.14.0 -> 0.15.0 would not).
If multiple Krill instances use the same shared data store (PostgreSQL), they should all run the same version of Krill - or bad things can and probably will happen.
The best way to prevent issues in this scenario would be to:
However, we cannot be sure that operators will always do this.
So, it would be very useful to modify or extend the
PropertiesManagerto support the notion of not just the current Krill version, but also of any upgrades that may be in progress.We can then use to do the following: