config services: services.cfg and validation

appengine/config_service/README.md

 # Configuration service
 
   - Stores and imports config files from repositories, such as Gitiles.
   - Provides read-only access to config files and encapsulates their location.
+  - Stores a registry of LUCI services.

[Vadim Sh., 2015/07/08 03:05:58]

"LUCI services that use config_service"?

auth_service also stores "a registry of LUCI services" in some way... There's no
real "registry".

[nodir, 2015/07/08 15:24:47]

services.cfg is meant to be the registry. 
Also see
https://docs.google.com/document/d/1EW3hwi9GZiJAxwpYbhFPopQCzXFabZeMWJuBsj7vb...

   - Stores a registry of projects that use LUCI services.
 
-
 ## Quick examples
 
 ### Service config example
 Auth service admins keep client id whitelist and configuration of group import
-from externa sources. They can store these configs as files in Gitiles.
-Config service can be configured to import them from Gitiles to
-to `services/auth` config set. Auth service can use config component to
-access its own configs.
+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
+[config component](../components/components/config) to access its the configs.
 
 As a result, Auth services has the following for free
 
   - convenient configuration viewing and editing by humans
   - change review and history
   - config ACLs
 
 
 ### Project config example
 
@@ skipping 28 matching lines @@
     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
     &lt;service-id&gt;.appspot.com.
 
-    `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.
-
   2. Project configs. Project-wide branch-independent configs for services.
     This is what a project as a tenant tells a service about itself. Examples:
 
     - project metadata: project name, project description, mailing list,
       owner email, team auth group, wiki link, etc.
     - list of project refs.
     - cron jobs: when and what project tasks to run.
 
     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.
 
   3. Ref configs. These are repository/branch-specific configs in a project.
     Examples:
 
     - list of builds that have to pass for a CL to be committed.
     - list of builder names that can close the tree if failed.
     - Code review info: type (rietveld, gerrit, etc), URL and
       codereview-specific details.
 
     Ref configs live in `projects/<project_id>/<ref_name>` config
     set, where `<ref_name>` always starts with `refs/`.
 
+## Project registry
+
+`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](proto/service_config.proto) for more info.
+
+## Service registry
+
+`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](proto/service_config.proto) for more info.
+
+## Configuration validation
+
+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](proto/service_config.proto) for more
+info.
 
 ## GAE component
 
-config component can be used by a GAE app to read configs.
-
+[config component](../components/components/config) can be used by a GAE app to
+read configs.
 
 ## Config import
 
 Configs are continuously imported from external sources to the datastore by
-config service backend.
+config service backend, with 10 min latency.
 [Read more](https://github.com/luci/luci-py/wiki/Config-service:-config-import)