@wallrj, @kragniz and I discussed the possibility of representing all the different state transitions when a user alters an ElasticsearchCluster resource as a finite state automata.
This would involve, at it's heart, a big 'switch style' statement (perhaps actually a series of if/else, depending on what's required). Each 'case' would represent a destination state, predicated with certain conditions (i.e. user wants to change version from 5.6.2->5.6.3, and cluster state is currently yellow, etc.).
This should make it easier to reason about the state of the world before we take action, making it easier to reason about what we're going to do as well as testing and proving it works.
For now, we'll need to handle the 'deadlock' case (e.g. where no progress can be made as the state of the world is 'unhandled' by logging messages to users.
@wallrj, @kragniz and I discussed the possibility of representing all the different state transitions when a user alters an ElasticsearchCluster resource as a finite state automata.
This would involve, at it's heart, a big 'switch style' statement (perhaps actually a series of if/else, depending on what's required). Each 'case' would represent a destination state, predicated with certain conditions (i.e. user wants to change version from 5.6.2->5.6.3, and cluster state is currently yellow, etc.).
This should make it easier to reason about the state of the world before we take action, making it easier to reason about what we're going to do as well as testing and proving it works.
For now, we'll need to handle the 'deadlock' case (e.g. where no progress can be made as the state of the world is 'unhandled' by logging messages to users.