Configuration Directory Layout¶
The layout of /etc/verwalter directory.
The directory layout is still in flux. Here are somewhat current draft.
scheduler– scheduler code in lua
scheduler/SCHEDULER_VERSION/main.lua– the entry point of the scheduler (
scheduler/SCHEDULER_VERSION/**/*.lua– other files that are
require’d from scheduler
templates– the templates to render configuration locally
runtime– the runtime metadata, mostly list of processes to run and other data needed for scheduling. Basically all of this is passed to the scheduler
runtime/ROLE/ROLE_VERSION– metadata dir for role and version
NAME.yaml– adds some metadata under key
NAME.json– just another format of the same thing
machine– the current machine metadata
NAME.json– adds some metadata under key
frontend– the files to render the frontend 
common/*– common files for the whole cluster (e.g. libraries)
ROLE/*– role-specific things 
sandbox– this contains some security configs:
- Logs that can be served within verwalter
- (TODO) commands to run from verwalter-render, run-as user, etc.
We avoid the term “application” here because it’s inherently vague. The role is just unit that may be deployed independendly (so it’s also versioned independently). The role may consists multiple applications or application may be built on top of multiple roles, dependening on use case and how you define the application.
|||(1, 2) The version of scheduler and version of templates is not the same as version of role (i.e. an application). It’s expected that scheduler and templates change very rarely and only by admins, not by release managers. Also you might use “shadow” scheduler and “shadow” template renderer for debugging.|
|||Each installation have different needs. So verwalter doesn’t have a frontend that is packaged with verwalter. We only provide the API, and a default (or example) frontend which you might use as a starting point. Sure verwalter serves static files so you don’t need to install a separate web server.|
|||We don’t have frontend files versioned yet. It’s not critical part of the system and it assumed that an (updated) frontend should support at least few versions of the application (role).|
It’s assumed that
templates are written by SysOps. They
should be versioned in version control system and deployed as needed.
frontend is very similar. It should be versioned too. It’s only
mentioned separately because usually changed by some frontender or release
engineer or whatever.
runtime folder is assumed to be deployed by buildbot. I.e. when build
is done, buildbot does two things to prepare deployment:
- Upload built image to all servers that will be able to run the application
- Put app metadata in the
runtimefolder on same machines
Then it’s up to the scheduler if it deploys the version automatically or waits for operator to trigger the update action.