+1 I have run into this issue before and it was very confusing.
On Tue, Mar 22, 2016 at 1:37 AM, tommy xiao <[email protected]> wrote: > yes, following apache upgrade doc guide, the step is master update firstly, > than upgrade slave. it can't support slave firstly. so this is rule on our > ops step. > > 2016-03-22 10:29 GMT+08:00 Benjamin Mahler <[email protected]>: > > > Hi folks, > > > > I wanted to surface the following ticket to our attention: > > https://issues.apache.org/jira/browse/MESOS-4997 > > > > The issue is that when enum fields are deserialized, unknown enum values > > are _stripped_. This means that if an enum field is 'required' and a new > > value is added, old clients cannot deserialize messages with the new enum > > value set: the message is considered to have a missing required field and > > is dropped. > > > > The suggested approach to ensure new enum values can be safely added is > the > > following: > > > > -Enum fields should be optional. > > -The first entry in an enum list should be UNKNOWN (and/or we set > [default > > = UNKNOWN]). > > > > Having them as optional ensures that the protobuf deserialization > considers > > messages with stripped enum fields to be initialized. Also, if our code > > calls the getter unconditionally it is safer to get UNKNOWN rather than > an > > arbitrary enum value (whatever happens to be the first in the list). > > > > I will follow up and ensure we fix this for FrameworkInfo::Capability, > > where we added a TASK_KILLING_STATE capability in 0.28. Frameworks that > try > > to set this new capability but talk to a 0.27 (or earlier) master will > not > > be able to register because the message will be dropped. > > > > Ben > > > > > > -- > Deshi Xiao > Twitter: xds2000 > E-mail: xiaods(AT)gmail.com > > -- > Zameer Manji > > <http://gmail.com>
