Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
api: Centralize defaults and add InterpolatedSpec
Currently, there is a problem with visibility of defaults. The best way to create a service is to only specify fields that you care about, because then the manager can apply appropriate defaults for the other fields. However, there's no way to know which values are actually being used for those fields. The spec is under the user's control, so if they don't specify a value (for example, `Spec.Task.Restart.Delay`), this field will show up as blank when the service is retrieved. We don't want to break the spec ownership model, but we do want a way to communicate actual values in use back to the client. For this, we add an `InterpolatedSpec` field which is inserted into the service object by the ControlAPI. `InterpolatedSpec` is a version of `Spec` that has unspecified fields filled in with default values, so the client can observe what values are actually in use. This also has the benefit of centralizing defaults. Default values for these fields that were defined in various places around the code are now centralized in `github.com/docker/swarmkit/api/defaults`. Right now InterpolatedSpec is only added to `Service`, but if we move forward with this, it would make sense to add it to other objects as well. The main question about this approach is whether we want to solve the defaults visibility problem by using this approach where defaults are substituted in, or by encouraging the client to set all fields instead of leaving some empty. There are advantages and disadvantages to each approach. The benefit of doing this client-side is that changes to default values won't affect existing services retroactively. However, expecting the client to fill in all fields with good defaults is expecting a lot, and would be a barrier to centralizing defaults. I think the best approach is to apply defaults on the manager side, but be conservative about changing defaults, knowing that it may have unexpected side effects. Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
- Loading branch information