New issue
Advanced search Search tips

Issue 842920 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 833946



Sign in to add a comment

Standardize proto package names of LUCI services

Project Member Reported by vadimsh@chromium.org, May 14 2018

Issue description

This is important if we want to use protos relating to multiple different services in one binary/script.

For example, trying to use both luci-milo and luci-notify protos from one binary doesn't work currently, because both use proto package named "config", and both define message named "ProjectConfig", so we end up with two config.ProjectConfig messages in one binary.

At least go protobuf lib doesn't allow this.

Proposal:
1. Use luci.<service>.config as proto package name for all proto messages that end up in LUCI configuration files (project level or service level).
2. Use luci.<service>.internal for all internal protos (the ones that do not leave boundaries of the service).
3. Use luci.<service>.api for protos with API service definitions.

The last item unfortunately introduces incompatible change in pRPC APIs since they use proto package name as part of the URL :( 

I'm going to do at least (1) for now, since this is needed for Skylark config generator.
 
Blocking: 833946
Few more potential gotchas:

1. Go's luci-config thick client uses fully qualified proto message names as part of datastore cache key. Changing proto package invalidates caches. I believe by default all luci-go services use "fail open" strategy [1] for cache missies, so everything should just work. Logdog though seems to be using "fail closed", so I can't predict what will happen if we rename logdog config protos.

2. 'tq' library uses fully qualified proto message names as part of task queue tasks. So its currently non-trivial to rename proto messages used to represent tq tasks.
After discussion with nodir@ we decided to do less renames. Now the only requirement is that protos for service X leave in proto package X or somewhere under package X. In particular all "public" messages (API definitions, config protos) should live directly in package X.

This makes all our pRPC definitions already compliant with the new rule. 
Status: Fixed (was: Assigned)
Good enough for now.

Sign in to add a comment