Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2243923002:
Refactors GCE backend config updates. (Closed)
|
Created:
4 years, 4 months ago by ryanmartens Modified:
4 years, 4 months ago CC:
chromium-reviews, infra-reviews+luci-py_chromium.org, smut_chromium.org Base URL:
https://chromium.googlesource.com/external/github.com/luci/luci-py@master Target Ref:
refs/heads/master Project:
luci-py Visibility:
Public. |
DescriptionRefactors GCE backend config updates.
Now uses the config component to update the cfg files.
R=maruel@chromium.org
BUG=
Committed: https://github.com/luci/luci-py/commit/dd556f127070ff5f4f6cfc4eabe004f7865b3862
Patch Set 1 #
Total comments: 16
Patch Set 2 : Refactors GCE backend config updates. #
Total comments: 5
Patch Set 3 : . #
Total comments: 2
Patch Set 4 : . #
Dependent Patchsets: Messages
Total messages: 21 (5 generated)
lgtm with comments https://codereview.chromium.org/2243923002/diff/1/appengine/gce-backend/confi... File appengine/gce-backend/config.py (right): https://codereview.chromium.org/2243923002/diff/1/appengine/gce-backend/confi... appengine/gce-backend/config.py:40: self.template_config = '' why not use default='' on each property? https://codereview.chromium.org/2243923002/diff/1/appengine/gce-backend/confi... appengine/gce-backend/config.py:54: protobuf.text_format.Merge(configuration.template_config, template_cfg) do you want to trap protobuf.text_format.ParseError and convert to ValueError? That's what auth_service does. https://codereview.chromium.org/2243923002/diff/1/appengine/gce-backend/confi... appengine/gce-backend/config.py:67: TEMPLATES_CFG_FILENAME, config_pb2.InstanceTemplateConfig, align arguments at +4 https://codereview.chromium.org/2243923002/diff/1/appengine/gce-backend/confi... appengine/gce-backend/config.py:87: if template_revision != manager_revision: I think this check should be done first (?) https://codereview.chromium.org/2243923002/diff/1/appengine/gce-backend/confi... appengine/gce-backend/config.py:88: logging.error('Not updating configuration due to revision mismatch.') warning? https://codereview.chromium.org/2243923002/diff/1/appengine/gce-backend/confi... appengine/gce-backend/config.py:92: if stored_config.revision != template_revision: No need to validate at every cron job when the stored version is the same (?) https://codereview.chromium.org/2243923002/diff/1/appengine/gce-backend/confi... appengine/gce-backend/config.py:95: manager_config = protobuf.text_format.MessageToString(manager_config), align at +4 while at it https://codereview.chromium.org/2243923002/diff/1/appengine/gce-backend/confi... appengine/gce-backend/config.py:118: @validation.self_rule(MANAGERS_CFG_FILENAME, @validation.self_rule( MANAGERS_CFG_FILENAME, config_pb2.InstanceGroupManagerConfig)
https://codereview.chromium.org/2243923002/diff/1/appengine/gce-backend/confi... File appengine/gce-backend/config.py (right): https://codereview.chromium.org/2243923002/diff/1/appengine/gce-backend/confi... appengine/gce-backend/config.py:40: self.template_config = '' On 2016/08/12 18:50:25, M-A Ruel wrote: > why not use default='' on each property? Done. https://codereview.chromium.org/2243923002/diff/1/appengine/gce-backend/confi... appengine/gce-backend/config.py:54: protobuf.text_format.Merge(configuration.template_config, template_cfg) On 2016/08/12 18:50:25, M-A Ruel wrote: > do you want to trap protobuf.text_format.ParseError and convert to ValueError? > That's what auth_service does. Sure. I've now loosely followed auth_service. It'd be nice to unify the two in the future by adding an ability in the config component to fetch a set of config files to ensure they are all in sync. Thoughts? https://codereview.chromium.org/2243923002/diff/1/appengine/gce-backend/confi... appengine/gce-backend/config.py:67: TEMPLATES_CFG_FILENAME, config_pb2.InstanceTemplateConfig, On 2016/08/12 18:50:25, M-A Ruel wrote: > align arguments at +4 Done. https://codereview.chromium.org/2243923002/diff/1/appengine/gce-backend/confi... appengine/gce-backend/config.py:87: if template_revision != manager_revision: On 2016/08/12 18:50:25, M-A Ruel wrote: > I think this check should be done first (?) Done. https://codereview.chromium.org/2243923002/diff/1/appengine/gce-backend/confi... appengine/gce-backend/config.py:88: logging.error('Not updating configuration due to revision mismatch.') On 2016/08/12 18:50:25, M-A Ruel wrote: > warning? Done. https://codereview.chromium.org/2243923002/diff/1/appengine/gce-backend/confi... appengine/gce-backend/config.py:92: if stored_config.revision != template_revision: On 2016/08/12 18:50:25, M-A Ruel wrote: > No need to validate at every cron job when the stored version is the same (?) Done. https://codereview.chromium.org/2243923002/diff/1/appengine/gce-backend/confi... appengine/gce-backend/config.py:95: manager_config = protobuf.text_format.MessageToString(manager_config), On 2016/08/12 18:50:25, M-A Ruel wrote: > align at +4 while at it Done. https://codereview.chromium.org/2243923002/diff/1/appengine/gce-backend/confi... appengine/gce-backend/config.py:118: @validation.self_rule(MANAGERS_CFG_FILENAME, On 2016/08/12 18:50:25, M-A Ruel wrote: > @validation.self_rule( > MANAGERS_CFG_FILENAME, config_pb2.InstanceGroupManagerConfig) Done.
smut@google.com changed reviewers: + smut@google.com
Is a component author just not considered the owner or what https://codereview.chromium.org/2243923002/diff/20001/appengine/gce-backend/c... File appengine/gce-backend/config.py (right): https://codereview.chromium.org/2243923002/diff/20001/appengine/gce-backend/c... appengine/gce-backend/config.py:70: template_revision, template_config = config.get_self_config( You can't get_self_config because the GCE Backend's self_config is google.com:gce-backend but in luci-config we have it as just gce-backend.
https://codereview.chromium.org/2243923002/diff/20001/appengine/gce-backend/c... File appengine/gce-backend/config.py (right): https://codereview.chromium.org/2243923002/diff/20001/appengine/gce-backend/c... appengine/gce-backend/config.py:70: template_revision, template_config = config.get_self_config( On 2016/08/12 21:34:56, smut wrote: > You can't get_self_config because the GCE Backend's self_config is > google.com:gce-backend but in luci-config we have it as just gce-backend. I'm confused, this kind of difference, where the GAE instance is hosted) vs where the GCE VMs are hosted, should be described explicitly in the configuration data. config.get_self_config(). So here, the config *is* for the project containing the GAE instance, not the one for the GCE hosting project.
https://codereview.chromium.org/2243923002/diff/20001/appengine/gce-backend/c... File appengine/gce-backend/config.py (right): https://codereview.chromium.org/2243923002/diff/20001/appengine/gce-backend/c... appengine/gce-backend/config.py:70: template_revision, template_config = config.get_self_config( On 2016/08/12 23:16:02, M-A Ruel wrote: > On 2016/08/12 21:34:56, smut wrote: > > You can't get_self_config because the GCE Backend's self_config is > > google.com:gce-backend but in luci-config we have it as just gce-backend. > > I'm confused, this kind of difference, where the GAE instance is hosted) vs > where the GCE VMs are hosted, should be described explicitly in the > configuration data. config.get_self_config(). > > So here, the config *is* for the project containing the GAE instance, not the > one for the GCE hosting project. This has nothing to do with the GCE hosting project. The GCE hosting project is google.com:chromecompute. This app itself is deployed as google.com:gce-backend. get_self_config queries luci-config for a set of configs for the service whose name matches the name of the running app. This app is deployed to gce-backend.googleplex.com which means its app ID is google.com:gce-backend. See this definition for get_self_config: https://chromium.googlesource.com/external/github.com/luci/luci-py/+/master/a... Note how it refers to common.self_config_set, which is defined here: https://chromium.googlesource.com/external/github.com/luci/luci-py/+/master/a... This calls app_identity.get_application_id(), which for my running instance will return google.com:gce-backend, which is not registered with luci-config. See the luci-config config for more info, but we registered this project as gce-backend, which does not match this deployed application's ID.
vadimsh@chromium.org changed reviewers: + vadimsh@chromium.org
https://codereview.chromium.org/2243923002/diff/20001/appengine/gce-backend/c... File appengine/gce-backend/config.py (right): https://codereview.chromium.org/2243923002/diff/20001/appengine/gce-backend/c... appengine/gce-backend/config.py:70: template_revision, template_config = config.get_self_config( On 2016/08/12 23:22:44, smut wrote: > On 2016/08/12 23:16:02, M-A Ruel wrote: > > On 2016/08/12 21:34:56, smut wrote: > > > You can't get_self_config because the GCE Backend's self_config is > > > google.com:gce-backend but in luci-config we have it as just gce-backend. > > > > I'm confused, this kind of difference, where the GAE instance is hosted) vs > > where the GCE VMs are hosted, should be described explicitly in the > > configuration data. config.get_self_config(). > > > > So here, the config *is* for the project containing the GAE instance, not the > > one for the GCE hosting project. > > This has nothing to do with the GCE hosting project. The GCE hosting project is > google.com:chromecompute. This app itself is deployed as google.com:gce-backend. > > get_self_config queries luci-config for a set of configs for the service whose > name matches the name of the running app. This app is deployed to > http://gce-backend.googleplex.com which means its app ID is google.com:gce-backend. > > See this definition for get_self_config: > https://chromium.googlesource.com/external/github.com/luci/luci-py/+/master/a... > > Note how it refers to common.self_config_set, which is defined here: > https://chromium.googlesource.com/external/github.com/luci/luci-py/+/master/a... > > This calls app_identity.get_application_id(), which for my running instance will > return google.com:gce-backend, which is not registered with luci-config. See the > luci-config config for more info, but we registered this project as gce-backend, > which does not match this deployed application's ID. I think it's safe to change get_self_config to always strip away "<domain>:" prefix. We do it in Go version already (using https://github.com/luci/gae/blob/master/service/info/interface.go#L52). Access is still properly enforced by checking service account email, e.g. https://chrome-internal.googlesource.com/infradata/config/+/master/configs/lu... So even if someone sets up *.appspot.com app names in the same way, it won't make a difference. As long as we ourselves don't have two identically named apps in two different domains, it should be fine. (So far, gce-backend is the only non-.appspot we have, so we'll need to change code only here).
On 2016/08/12 23:54:24, Vadim Sh. wrote: > https://codereview.chromium.org/2243923002/diff/20001/appengine/gce-backend/c... > File appengine/gce-backend/config.py (right): > > https://codereview.chromium.org/2243923002/diff/20001/appengine/gce-backend/c... > appengine/gce-backend/config.py:70: template_revision, template_config = > config.get_self_config( > On 2016/08/12 23:22:44, smut wrote: > > On 2016/08/12 23:16:02, M-A Ruel wrote: > > > On 2016/08/12 21:34:56, smut wrote: > > > > You can't get_self_config because the GCE Backend's self_config is > > > > google.com:gce-backend but in luci-config we have it as just gce-backend. > > > > > > I'm confused, this kind of difference, where the GAE instance is hosted) vs > > > where the GCE VMs are hosted, should be described explicitly in the > > > configuration data. config.get_self_config(). > > > > > > So here, the config *is* for the project containing the GAE instance, not > the > > > one for the GCE hosting project. > > > > This has nothing to do with the GCE hosting project. The GCE hosting project > is > > google.com:chromecompute. This app itself is deployed as > google.com:gce-backend. > > > > get_self_config queries luci-config for a set of configs for the service whose > > name matches the name of the running app. This app is deployed to > > http://gce-backend.googleplex.com which means its app ID is > google.com:gce-backend. > > > > See this definition for get_self_config: > > > https://chromium.googlesource.com/external/github.com/luci/luci-py/+/master/a... > > > > Note how it refers to common.self_config_set, which is defined here: > > > https://chromium.googlesource.com/external/github.com/luci/luci-py/+/master/a... > > > > This calls app_identity.get_application_id(), which for my running instance > will > > return google.com:gce-backend, which is not registered with luci-config. See > the > > luci-config config for more info, but we registered this project as > gce-backend, > > which does not match this deployed application's ID. > > I think it's safe to change get_self_config to always strip away "<domain>:" > prefix. We do it in Go version already (using > https://github.com/luci/gae/blob/master/service/info/interface.go#L52). > > Access is still properly enforced by checking service account email, e.g. > https://chrome-internal.googlesource.com/infradata/config/+/master/configs/lu... > > So even if someone sets up *.appspot.com app names in the same way, it won't > make a difference. As long as we ourselves don't have two identically named apps > in two different domains, it should be fine. > > (So far, gce-backend is the only non-.appspot we have, so we'll need to change > code only here). Alternatively, we can teach luci-config itself to strip away domain prefix when searching for a directory with configs. Or replace ":" with "/", e.g. use "services/google.com/gce-backend" for project with ID "google.com:gce-backend". But it is more difficult change. I'm not sure what else can break if we start using ":" service identifiers. It was oversight on our side, since we never had to deal with non-appspot apps before gce-backend :(
On 2016/08/12 23:57:11, Vadim Sh. wrote: > On 2016/08/12 23:54:24, Vadim Sh. wrote: > > > https://codereview.chromium.org/2243923002/diff/20001/appengine/gce-backend/c... > > File appengine/gce-backend/config.py (right): > > > > > https://codereview.chromium.org/2243923002/diff/20001/appengine/gce-backend/c... > > appengine/gce-backend/config.py:70: template_revision, template_config = > > config.get_self_config( > > On 2016/08/12 23:22:44, smut wrote: > > > On 2016/08/12 23:16:02, M-A Ruel wrote: > > > > On 2016/08/12 21:34:56, smut wrote: > > > > > You can't get_self_config because the GCE Backend's self_config is > > > > > google.com:gce-backend but in luci-config we have it as just > gce-backend. > > > > > > > > I'm confused, this kind of difference, where the GAE instance is hosted) > vs > > > > where the GCE VMs are hosted, should be described explicitly in the > > > > configuration data. config.get_self_config(). > > > > > > > > So here, the config *is* for the project containing the GAE instance, not > > the > > > > one for the GCE hosting project. > > > > > > This has nothing to do with the GCE hosting project. The GCE hosting project > > is > > > google.com:chromecompute. This app itself is deployed as > > google.com:gce-backend. > > > > > > get_self_config queries luci-config for a set of configs for the service > whose > > > name matches the name of the running app. This app is deployed to > > > http://gce-backend.googleplex.com which means its app ID is > > google.com:gce-backend. > > > > > > See this definition for get_self_config: > > > > > > https://chromium.googlesource.com/external/github.com/luci/luci-py/+/master/a... > > > > > > Note how it refers to common.self_config_set, which is defined here: > > > > > > https://chromium.googlesource.com/external/github.com/luci/luci-py/+/master/a... > > > > > > This calls app_identity.get_application_id(), which for my running instance > > will > > > return google.com:gce-backend, which is not registered with luci-config. See > > the > > > luci-config config for more info, but we registered this project as > > gce-backend, > > > which does not match this deployed application's ID. > > > > I think it's safe to change get_self_config to always strip away "<domain>:" > > prefix. We do it in Go version already (using > > https://github.com/luci/gae/blob/master/service/info/interface.go#L52). > > > > Access is still properly enforced by checking service account email, e.g. > > > https://chrome-internal.googlesource.com/infradata/config/+/master/configs/lu... > > > > So even if someone sets up *.appspot.com app names in the same way, it won't > > make a difference. As long as we ourselves don't have two identically named > apps > > in two different domains, it should be fine. > > > > (So far, gce-backend is the only non-.appspot we have, so we'll need to change > > code only here). > > Alternatively, we can teach luci-config itself to strip away domain prefix when > searching for a directory with configs. Or replace ":" with "/", e.g. use > "services/google.com/gce-backend" for project with ID "google.com:gce-backend". > > But it is more difficult change. I'm not sure what else can break if we start > using ":" service identifiers. > > It was oversight on our side, since we never had to deal with non-appspot apps > before gce-backend :( a valid service id cannot have "/" or ":" https://cs.chromium.org/chromium/infra/luci/appengine/components/components/c... we typically use ":" to separate config set and path, so better not to allow ":" we will use slashes in luci-config v2 REST API, so better not to allow "/" we should probably modify get_self_config to replace ":google.com" with something allowed, how about "_google"? note that appid cannot contains "_" you can do it in this CL
On 2016/08/13 00:04:03, nodir wrote: > On 2016/08/12 23:57:11, Vadim Sh. wrote: > > On 2016/08/12 23:54:24, Vadim Sh. wrote: > > > > > > https://codereview.chromium.org/2243923002/diff/20001/appengine/gce-backend/c... > > > File appengine/gce-backend/config.py (right): > > > > > > > > > https://codereview.chromium.org/2243923002/diff/20001/appengine/gce-backend/c... > > > appengine/gce-backend/config.py:70: template_revision, template_config = > > > config.get_self_config( > > > On 2016/08/12 23:22:44, smut wrote: > > > > On 2016/08/12 23:16:02, M-A Ruel wrote: > > > > > On 2016/08/12 21:34:56, smut wrote: > > > > > > You can't get_self_config because the GCE Backend's self_config is > > > > > > google.com:gce-backend but in luci-config we have it as just > > gce-backend. > > > > > > > > > > I'm confused, this kind of difference, where the GAE instance is hosted) > > vs > > > > > where the GCE VMs are hosted, should be described explicitly in the > > > > > configuration data. config.get_self_config(). > > > > > > > > > > So here, the config *is* for the project containing the GAE instance, > not > > > the > > > > > one for the GCE hosting project. > > > > > > > > This has nothing to do with the GCE hosting project. The GCE hosting > project > > > is > > > > google.com:chromecompute. This app itself is deployed as > > > google.com:gce-backend. > > > > > > > > get_self_config queries luci-config for a set of configs for the service > > whose > > > > name matches the name of the running app. This app is deployed to > > > > http://gce-backend.googleplex.com which means its app ID is > > > google.com:gce-backend. > > > > > > > > See this definition for get_self_config: > > > > > > > > > > https://chromium.googlesource.com/external/github.com/luci/luci-py/+/master/a... > > > > > > > > Note how it refers to common.self_config_set, which is defined here: > > > > > > > > > > https://chromium.googlesource.com/external/github.com/luci/luci-py/+/master/a... > > > > > > > > This calls app_identity.get_application_id(), which for my running > instance > > > will > > > > return google.com:gce-backend, which is not registered with luci-config. > See > > > the > > > > luci-config config for more info, but we registered this project as > > > gce-backend, > > > > which does not match this deployed application's ID. > > > > > > I think it's safe to change get_self_config to always strip away "<domain>:" > > > prefix. We do it in Go version already (using > > > https://github.com/luci/gae/blob/master/service/info/interface.go#L52). > > > > > > Access is still properly enforced by checking service account email, e.g. > > > > > > https://chrome-internal.googlesource.com/infradata/config/+/master/configs/lu... > > > > > > So even if someone sets up *.appspot.com app names in the same way, it won't > > > make a difference. As long as we ourselves don't have two identically named > > apps > > > in two different domains, it should be fine. > > > > > > (So far, gce-backend is the only non-.appspot we have, so we'll need to > change > > > code only here). > > > > Alternatively, we can teach luci-config itself to strip away domain prefix > when > > searching for a directory with configs. Or replace ":" with "/", e.g. use > > "services/google.com/gce-backend" for project with ID > "google.com:gce-backend". > > > > But it is more difficult change. I'm not sure what else can break if we start > > using ":" service identifiers. > > > > It was oversight on our side, since we never had to deal with non-appspot apps > > before gce-backend :( > > a valid service id cannot have "/" or ":" > https://cs.chromium.org/chromium/infra/luci/appengine/components/components/c... > we typically use ":" to separate config set and path, so better not to allow ":" > we will use slashes in luci-config v2 REST API, so better not to allow "/" > > we should probably modify get_self_config to replace ":google.com" with > something allowed, how about "_google"? note that appid cannot contains "_" > > you can do it in this CL Just replace "google.com:" with "" otherwise we will have to register google_gce-backend with luci-config.
https://codereview.chromium.org/2243923002/diff/20001/appengine/gce-backend/c... File appengine/gce-backend/config.py (right): https://codereview.chromium.org/2243923002/diff/20001/appengine/gce-backend/c... appengine/gce-backend/config.py:70: template_revision, template_config = config.get_self_config( On 2016/08/12 23:54:24, Vadim Sh. wrote: > On 2016/08/12 23:22:44, smut wrote: > > On 2016/08/12 23:16:02, M-A Ruel wrote: > > > On 2016/08/12 21:34:56, smut wrote: > > > > You can't get_self_config because the GCE Backend's self_config is > > > > google.com:gce-backend but in luci-config we have it as just gce-backend. > > > > > > I'm confused, this kind of difference, where the GAE instance is hosted) vs > > > where the GCE VMs are hosted, should be described explicitly in the > > > configuration data. config.get_self_config(). > > > > > > So here, the config *is* for the project containing the GAE instance, not > the > > > one for the GCE hosting project. > > > > This has nothing to do with the GCE hosting project. The GCE hosting project > is > > google.com:chromecompute. This app itself is deployed as > google.com:gce-backend. > > > > get_self_config queries luci-config for a set of configs for the service whose > > name matches the name of the running app. This app is deployed to > > http://gce-backend.googleplex.com which means its app ID is > google.com:gce-backend. > > > > See this definition for get_self_config: > > > https://chromium.googlesource.com/external/github.com/luci/luci-py/+/master/a... > > > > Note how it refers to common.self_config_set, which is defined here: > > > https://chromium.googlesource.com/external/github.com/luci/luci-py/+/master/a... > > > > This calls app_identity.get_application_id(), which for my running instance > will > > return google.com:gce-backend, which is not registered with luci-config. See > the > > luci-config config for more info, but we registered this project as > gce-backend, > > which does not match this deployed application's ID. > > I think it's safe to change get_self_config to always strip away "<domain>:" > prefix. We do it in Go version already (using > https://github.com/luci/gae/blob/master/service/info/interface.go#L52). > > Access is still properly enforced by checking service account email, e.g. > https://chrome-internal.googlesource.com/infradata/config/+/master/configs/lu... > > So even if someone sets up *.appspot.com app names in the same way, it won't > make a difference. As long as we ourselves don't have two identically named apps > in two different domains, it should be fine. > > (So far, gce-backend is the only non-.appspot we have, so we'll need to change > code only here). I went with the last solution proposed and trimmed 'google.com:' from the app id prefix for self-configs. Thanks for catching this issue.
https://codereview.chromium.org/2243923002/diff/40001/appengine/components/co... File appengine/components/components/config/common.py (right): https://codereview.chromium.org/2243923002/diff/40001/appengine/components/co... appengine/components/components/config/common.py:113: app_id_match = APP_PREFIX_RGX.match(app_id) Please make it generic, technically they could be hosted on any GAIA domain. No need for a regexp; return app_id.split(':')[-1] is both faster, simpler to understand and just works.
https://codereview.chromium.org/2243923002/diff/40001/appengine/components/co... File appengine/components/components/config/common.py (right): https://codereview.chromium.org/2243923002/diff/40001/appengine/components/co... appengine/components/components/config/common.py:113: app_id_match = APP_PREFIX_RGX.match(app_id) On 2016/08/15 17:18:55, M-A Ruel wrote: > Please make it generic, technically they could be hosted on any GAIA domain. No > need for a regexp; > > return app_id.split(':')[-1] > > is both faster, simpler to understand and just works. Makes sense. My intent was to limit this only to the `google.com` domain, but this is definitely much simpler to understand.
On 2016/08/15 17:51:59, ryanmartens wrote: > https://codereview.chromium.org/2243923002/diff/40001/appengine/components/co... > File appengine/components/components/config/common.py (right): > > https://codereview.chromium.org/2243923002/diff/40001/appengine/components/co... > appengine/components/components/config/common.py:113: app_id_match = > APP_PREFIX_RGX.match(app_id) > On 2016/08/15 17:18:55, M-A Ruel wrote: > > Please make it generic, technically they could be hosted on any GAIA domain. > No > > need for a regexp; > > > > return app_id.split(':')[-1] > > > > is both faster, simpler to understand and just works. > > Makes sense. My intent was to limit this only to the `google.com` domain, but > this is definitely much simpler to understand. oh, i thought you could have different apps in different domains with same app id if you cannot, then trimming ":<domain>" is definitely better
The CQ bit was checked by ryanmartens@google.com
The patchset sent to the CQ was uploaded after l-g-t-m from maruel@chromium.org Link to the patchset: https://codereview.chromium.org/2243923002/#ps60001 (title: ".")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Description was changed from ========== Refactors GCE backend config updates. Now uses the config component to update the cfg files. R=maruel@chromium.org BUG= ========== to ========== Refactors GCE backend config updates. Now uses the config component to update the cfg files. R=maruel@chromium.org BUG= Committed: https://github.com/luci/luci-py/commit/dd556f127070ff5f4f6cfc4eabe004f7865b3862 ==========
Message was sent while issue was closed.
Committed patchset #4 (id:60001) as https://github.com/luci/luci-py/commit/dd556f127070ff5f4f6cfc4eabe004f7865b3862 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
