Auth service admins keep client id whitelist and configuration of group import from external sources. These configs are stored as files in Gitiles. Config service imports them from Gitiles to services/<auth-service-app-id>
config set. Auth service can use components/config to access its the configs.
As a result, Auth services has the following for free
Project chromium is a tenant of Swarming service. Swarming is chromum-independent therefore it does not contain configuration for chromium, but chromium needs to supply its config to swarming. Chromium configs can be stored in chromium repository and be imported into projects/chromium
config set. projects.cfg
in services/luci-config
config set contains a list of projects served by LUCI services. For each project, Swarming uses config component to read swarming.cfg
from projects/<project id>
config set.
services/chrome-infra-auth
, projects/chromium
, projects/chromium/refs/heads/master
. Config sets encapsulate location of files. Config service API accepts config sets instead of repository URLs. services/luci-config:projects.cfg
means projects.cfg
file in services/luci-config
config set.There are three types of configs:
Service configs. A service may have a global project-independent config. Example: auth service has a whiltelist of oauth2 client ids. These configs are generally not interesting to project maintainers.
Service configs live in services/<service_id>
config sets. For GAE apps, service_id
is an app id. Examples: services/luci-config
, services/chrome-infra-auth
. A service typically reads config files in its own config set.
services/<service_id>
is always accessible to <service-id>.appspot.com.
Project configs. Project-wide branch-independent configs for services. This is what a project as a tenant tells a service about itself. Examples:
Project configs live in projects/<project_id>
config set. Services discover projects through get_projects()
and request a config from projects/<project_id>
config set. For instance, cron service reads projects/<project_id>:cron.cfg
for each project in the registry.
Ref configs. These are repository/branch-specific configs in a project. Examples:
Ref configs live in projects/<project_id>/<ref_name>
config set, where <ref_name>
always starts with refs/
.
services/luci-config:projects.cfg
is a project registry. It contains unique project ids (chromium, v8, skia) and location of project configs. This list is available through get_projects() API. This is how projects are discovered by services.
See ProjectsCfg message for more info.
services/luci-config:services.cfg
is a service registry. It contains unique service ids (chrome-infra-auth, swarming), location of configs if different from default and metadata url.
See ServicesCfg message for more info.
Service configs are accessible to a group defined in service/luci-config:acl.cfg and a GAE app with the same id, e.g. x.appspot.com has access to services/x
.
Projects define access to their configs in projects/foo:project.cfg. See access field in ProjectCfg message for more info.
Config files are validated and config set revisions containing invalid configs are not imported. Configs of the config service (services/luci-config config set) are validated by the config service. Other configs can be validated by registered services. A service may expose a list of config patterns that it is able to validate and the config service will call service's endpoint to validate.
See ServicesCfg and Validator messages for more info.
Configs are continuously imported from external sources to the datastore by config service backend, with 10 min latency. Read more
Use components/config in a GAE app to read configs.