Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move mission queue from Flotilla to ISAR #674

Open
andchiind opened this issue Dec 12, 2024 · 0 comments
Open

Move mission queue from Flotilla to ISAR #674

andchiind opened this issue Dec 12, 2024 · 0 comments
Labels
breaking-change A breaking change which introduces changes to the public APIs improvement Improvement to existing functionality

Comments

@andchiind
Copy link
Contributor

andchiind commented Dec 12, 2024

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.

@andchiind andchiind added breaking-change A breaking change which introduces changes to the public APIs improvement Improvement to existing functionality labels Dec 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking-change A breaking change which introduces changes to the public APIs improvement Improvement to existing functionality
Projects
None yet
Development

No branches or pull requests

1 participant