Thanks Ben! I think that we can take care of this issue by either examining
the version present in 'MasterInfo', or by introducing a new master
capability.

So, no need for constrained upgrades after all.

Cheers,
Greg

On Tue, Apr 10, 2018 at 5:48 PM, Benjamin Mahler <bmah...@apache.org> wrote:

> -user
>
> Do you have a link to the technical details of why this needs to be done?
>
> For instance, why can't master/agent versions be used to determine which
> behavior is performed between the master and agent?
>
> On Tue, Apr 10, 2018 at 5:34 PM, Greg Mann <g...@mesosphere.io> wrote:
>
> > Hi all,
> > We are currently working on patches to implement the new GROW_VOLUME and
> > SHRINK_VOLUME operations [1]. In order to make it into Mesos 1.6, we're
> > pursuing a workaround which affects the way these operations are
> accounted
> > for in the Mesos master. These operations will be marked as
> *experimental* in
> > Mesos 1.6.
> >
> > As a result of this workaround, upgrades from Mesos 1.6 to later versions
> > would be affected. Specifically, 1.6 masters would not be able to
> properly
> > account for the resources of failed GROW/SHRINK operations on 1.7+
> agents.
> > This means that when upgrading from Mesos 1.6, if GROW_VOLUME or
> > SHRINK_VOLUME operations are being used during the upgrade, the masters
> > *must* be upgraded first. If we follow this proposal, this constraint
> > would be clearly spelled out in our upgrade documentation.
> >
> > Since, in general, we guarantee compatibility between Mesos masters and
> > agents of the same major version, we wanted to check with the community
> to
> > see if this constraint on 1.6 upgrades would be acceptable. Please let us
> > know what you think!
> >
> > Cheers,
> > Greg
> >
> >
> > [1] https://issues.apache.org/jira/browse/MESOS-4965
> >
>

Reply via email to