Hubops Mission Manager
Originally
ADR-0021-HUBOPS-MISSION-MANAGER (v3) · Source on Confluence ↗HubOps Mission Manager
Context
Today, numberous HubOps functionalities interact and depend on FlightOps. Relying entirely in FlightOps being constantly available, operational and unpredictable is hindering HubOps’ ability to develop and test those functionalities. A solution is required to eliminate the dependency on FlightOps when the results of the communication with it are irrelevant to the rest of the functionality that is being developed.
The following calls to flightops are being made, and require mocks:
- Mission creation - called by GCP function and Hubops API, handled by “flightops listener” service, living in droneup-flightops
- Elevation request - called by GCP function, handled by “flightops listener” service, living in droneup-flightops
- Air Vehicle request - called by GCP function and Hubops API, handled by “flightops listener” service, living in droneup-flightops
- Retrieval of mission’s calculated route - called by Hubops API
- Listening for mission telemetry/events - performed in Hubops Status Manager Service
In addition, in the future, the following Uncrew capabilities will also be mocked. These calls are made by the Hubops Mission
- Create Mission Request
- Get Mission Events
Moving existing legacy service functionalities into this service will allow for control and observability over components that HubOps does not currently have.
Decision
Create a “middleware” service that will stand between Hubops services and FlightOps and abstract that away. Use that service to switch between using FlightOps and using newly created mocks, that will enable us to efficiently build, test and validate functionalities, without relying on the actual FlightOps system.
This service can then be exteded further in the future to also abstract and mock Uncrew, and act as a switch between Uncrew and FlightOps, and also host new functionalities that rely on abstracting flightops/uncrew data. However, initial purpose of this service will be to host flightops mocks.
Connectivity:
Connection between the Hubops API and this service will be established via gRPC. A .proto will be created in the mission manager repository and imported in the API.
This service will also expose an HTTP port. A rest API will be created that will enable engineers to send on demand flightops mission events, that translate to the following hubops delivery statuses:
- Started
- Outbound Leg Completed
- Inbound Leg Completed
- Stopped
The first version of the service’s gRPC template will contain the contracts for Mission creation and Elevation request.
The service will use FrontEgg for authentication.
- it will also be able to receive pub/sub messages for communication with the Hubops GCP functions and services subscribing to flight events.
The mock responses generated by this service should in no case be any different than actual FlightOps/Uncrew responses.
As an output this service will be able to write mocked data into firestore, or push it via pub/sub to subscribed.
Service will be created in the hubops-droneup project.
It will have access permissions for the droneup-deliveries pub/sub (in addition to pub/subs in the Hubops GCP project).
Alternatives considered
Use an existing service to host flightops mocks
Main alternative would be to not create a new service, but use an existing one instead, to host flightops mocks and future functionalities, coupling them with existing API functionalities.
The service that can accomodate that is the Hubops API, but there are concerns about its rapidly growing number of responsibilities and connections to external services.
Consequences
HubOps’ ecosystem will grow with another microservice that is solely responsible for missions and mission objectives management.