KubOS 1.19 Scheduling
November 7, 2019
This latest release of KubOS includes an entirely new service that significantly changes the way you interact with KubOS: the scheduler service. The implications are far reaching, and we’re excited to finally bring it to our users. We removed the OnBoot and OnCommand reserved args in the application service, as the OnBoot functionality is now achieved through the scheduler. In addition, we’ve made several small changes to improve quality of life for our users and make the system more robust.
Scheduler Service
The scheduler service not only brings in the notion of scheduled execution of tasks, but it also allows you to group those tasks to create satellite modes. This is the first time we’ve really incorporated system-level state into KubOS, and, as you might imagine, it’s a really big deal. Instead of a collection of apps and services that all act independently, the mode that the scheduler is in will dictate what schedule it’s executing, which means you can cohesively plan the boot up behavior, operational behavior, or safe-mode behavior all in a single place in human readable JSON schedule files.
Application Service Args
As a result of this new behavior, we have also removed the concept of OnBoot and OnCommand default args for mission applications. Since you are able to schedule the running of applications on boot through the scheduler or execute them ad-hoc through the GraphQL interface, we removed the duplicate functionality to avoid confusing mission developers. If you have more questions about this decision, please come talk to us!
Check Out the Docs
There is quite a bit more information about the capabilities and behavior of the scheduler service, and I highly suggest reading the service documentation and working through the tutorial to learn more.
Helping Out Our Users
We are continuously trying to improve the user experience of KubOS, and we have incorporated a few changes to make life a bit easier for our users.
Running Locally
Not everyone has immediate access to hardware or even wants to mess with hardware. We have made several changes and improvements to help out those users that are trying to run and develop on KubOS locally:
- We’ve added a
local_config.tomlto thetoolsfolder with defaults set up for running all the core services locally without editing. - We have a new doc: I Don’t Have Hardware Yet, What Can I Do?
- Running core services locally with the
--stdoutflag will allow you to see the console output.
New Default Service Locations
All services now have assigned default port locations that are reflected throughout the entirety of KubOS. This allows you to intuit the location of any given service without having to look it up in the config.toml of the system every time. Also, you know where you can put your payload/hardware services and can be confident you won’t step on other service ports.
As Always…
Check out the changelog for the full list of changes with this release! If you have any feedback/issues/wonderful words for our team, you can always come talk to us on Slack, or open an issue on our GitHub. For all of you out there looking to contribute to KubOS, please check out our guide to contributing, and please give us feedback on how we can make it easier for you! We’re always looking to make sure we serve our community of contributors, and we’re actively looking for more ideas of how to do so.
