2.3 KiB
hub-and-spoke architecture
The "Hub" runs the web application and talks to the Postgres database, while the "Spoke"s are responsible for creating/managing virtual machines. One instance of the capsul-flask application can run in hub mode and spoke mode at the same time.
The Hub and the Spoke must be configured to communicate securely with each-other over HTTPS. They both have to be able to dial each-other directly. The URLs / auth tokens they use are configured both in the config file (HUB_URL, SPOKE_HOST_ID, SPOKE_HOST_TOKEN and HUB_TOKEN) and in the database (the id, https_url, and token columns in the hosts table).
This diagram was created with https://app.diagrams.net/. To edit it, download the diagram file and edit it with the https://app.diagrams.net/ web application, or you may run the application from source if you wish.
right now I have 2 types of operations, immediate mode and async.
both types of operations do assignment synchronously. so if the system cant assign the operation to one or more hosts (spokes), or whatever the operation requires, then it will fail.
some operations tolerate partial failures, like, capacity_avaliable will succeed if at least one spoke succeeds.
for immediate mode requests (like list, capacity_avaliable, destroy), assignment and completion of the operation are the same thing.
for async ones, they can be assigned without knowing whether or not they succeeded (create).
This diagram was created with https://app.diagrams.net/. To edit it, download the diagram file and edit it with the https://app.diagrams.net/ web application, or you may run the application from source if you wish.
if you issue a create, and it technically could go to any number of hosts, but only one host responds, it will succeed but if you issue a create and somehow 2 hosts both think they own that task, it will fail and throw a big error. cuz it expects exactly 1 to own the create task
currently its not set up to do any polling. its not really like a queue at all. It's all immediate for the most part