mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yan Xu <>
Subject How to consistent handle default values for message types
Date Thu, 02 Feb 2017 20:06:59 GMT
With protobuf you can specify custom default values for scalar types
(proto2 at least) but not message types, e.g.,

message Filters {
  // Time to consider unused resources refused. Note that all unused
  // resources will be considered refused and use the default value
  // (below) regardless of whether Filters was passed to
  // SchedulerDriver::launchTasks. You MUST pass Filters with this
  // field set to change this behavior (i.e., get another offer which
  // includes unused resources sooner or later than the default).
  optional double refuse_seconds = 1 [default = 5.0];

However, the message `Filters` essential has a default value because *all* its
fields have default values. It all depends on whether the receiver chooses
to check it is not set or directly accesses it and gets the default values.

When we reference the type in other messages, e.g.,

  message Accept {
    repeated OfferID offer_ids = 1;
    repeated Offer.Operation operations = 2;
    optional Filters filters = 3;

We are not explicitly telling users what's going to happen when `filters`
is not set. The master just directly uses it without checking.

It does feel intuitive to me that "*if all the fields in a message have
default values, and it semantically feels like a config, then we can just
interpret them when unset as indication to use defaults*".

However we probably should document it better.

To generalize it further, for something like this with multiple fields

message ExponentialBackoff {
  optional double initial_interval_seconds = 1 [default = 0.5];
  optional double max_interval_seconds = 2 [default = 300.0];
  optional double randomization_factor = 3 [default = 0.5];
  optional double max_elapsed_seconds = 4 [default = 2592000.0];

we should be able to not require them to be set and assume the defaults?

One step further, if the message has recursively nested messages with
default values, we can treat the parent message as having a default value



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message