config services: services.cfg and validation

appengine/config_service/README.md

Index: appengine/config_service/README.md
diff --git a/appengine/config_service/README.md b/appengine/config_service/README.md
index 64a65d68bad51ba8de169101dbb4bd69420fc5c2..c10568a94ea949405e7708826ba71c8b4d3c0e47 100644
--- a/appengine/config_service/README.md
+++ b/appengine/config_service/README.md
@@ -2,17 +2,17 @@
 
   - 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
 
@@ -61,11 +61,6 @@ There are three types of configs:
     `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:
 
@@ -90,14 +85,42 @@ There are three types of configs:
     Ref configs live in `projects/<project_id>/<ref_name>` config
     set, where `<ref_name>` always starts with `refs/`.
 
+## Project registry
 
-## GAE component
+`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.
 
-config component can be used by a GAE app to read configs.
+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](../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)