Move mission queue from Flotilla to ISAR #674
Labels
breaking-change
A breaking change which introduces changes to the public APIs
improvement
Improvement to existing functionality
Describe the improvement you would like to see
I want the isar instances to store a queue of missions relevant to their robot. When an API call is made to schedule a mission, the robot should add it to the queue, or start it if the queue is empty, and then return this information as a response to the POST API call. If the mission is queued and not scheduled, then we should return the queue in the response. When a mission is started from the queue, this should be reported on MQTT and reported back to the user. Mission status should be reported but not dictated by Flotilla.
How will this change existing functionality?
Using an SQL database is not suitable for storing the queue in Flotilla, as we have no way of ensuring consistency between the different Flotilla pods when writing/reading from this database. We are in effect storing many instances of the queue in memory across different Flotilla instances and sometimes updating the database to reflect this, which leads to inconcistencies. ISAR on the other hand only has one state for one robot, meaning that it will always be able to maintain consistency, as long as the queue is stored in a thread-safe queue (which we already do for other queues in ISAR, such as the upload queue). I consider this change to be necessary to ensure a stable system.
How will this improvement affect the current Threat Model?
It will patch up vulnerabilities related to the distributed nature of the Flotilla system.
The text was updated successfully, but these errors were encountered: