yes, haosdent is right. the master and slave is connected with protobuf. we need upgrade version one by one. don't skip minor version.
2016-05-26 1:25 GMT+08:00 haosdent <[email protected]>: > >does that make the KILLED or LOST > Yes, `rm -f /data/mesos/meta/slaves/latest` make it KILLED and LOST become > those containers could not be recovered. > > >but what's cause the result in case2 ? > For upgrade, cross multiple versions upgrading is not supported. For > example, if we want to upgrade from 0.21.0 to 0.25.0, we need to upgrade > the cluster to 0.22 first, then upgrade to 0.23, 0.24 and 0.25.0. > > On Wed, May 25, 2016 at 10:54 AM, Qiang Chen <[email protected]> wrote: > >> >> >> On 2016年05月25日 10:11, haosdent wrote: >> >> > but come to step 3, why the running containers become KILLED or LOST ? >> If you removed the work_dir of slave, or some break changes make slave >> could not recover those containers successfully, they would be killed. >> >> we executed "rm -f /data/mesos/meta/slaves/latest" and restart docker >> services before installing new mesos version to avoid mesos-slave fails >> starting for all mesos-agents. does that make the KILLED or LOST ? or it >> need restart docker service in the process of upgrading mesos ? >> >> > But why suppose upgrade mesos-master before mesos-slave in the Apach >> Mesos official site ? there any good idea to do that ? >> I think most contributors suppose user upgrade mesos-master first when >> introduce some break changes into Mesos. >> For example, we updated the MasterInfo format from protobuf to json >> before. >> What we do at that time is make the new version of Mesos Master suppose >> both protobuf and json, so no matter old slave or new slave could >> communicate with Master successfully. >> But if you update slave in this case, new slave suppose the format of >> MasterInfo is json and when it communicate with the old Master, something >> wrong may happen.... >> >> it makes sense for the explanation, but we met the case when upgrading >> mesos from mesos 0.21.0 to 0.25.0 before, the communication between each >> other the status as belows: >> >> 1. mesos-master 0.21.0 with mesos-slave 0.25.0 , they work good, can >> communicate with each other. >> 2. mesos-master 0.25.0 with mesos-slave 0.21.0, will see no slaves are >> listed in the mesos ui (<master:5050>), but the slaves with old version are >> running in the backend. >> >> so, we upgrade mesos-slave first, then mesos-master. but what's cause the >> result in case2 ? >> >> On Tue, May 24, 2016 at 6:43 PM, Qiang Chen <[email protected]> wrote: >> >>> Hi haosdent, >>> >>> I have 2 questions. >>> >>> Q1. When I upgrade a mesos cluster by following steps: >>> >>> 1. stop mesos-slave and uninstall mesos old version >>> 2. install mesos new version >>> 3. start mesos-slave >>> >>> In step 1 & 2, the docker containers run in the mesos-agent keeps >>> running.. >>> but come to step 3, why the running containers become KILLED or LOST ? >>> >>> So it will affect the running tasks when upgrade that slave, although it >>> will reschedule and starts all the tasks to other slaves in the upgrade >>> process. >>> But I think it shouldn't affect running tasks in the process of >>> upgarding... it's make sense ? any good suggestion when upgrading ? >>> >>> >>> Q2. I think the upgrade sequence is as belows: >>> >>> 1. upgrade mesos-slave >>> 2. upgrade mesos-master >>> 3. updrade frameworks to adapt the new mesos version >>> >>> But why suppose upgrade mesos-master before mesos-slave in the Apach >>> Mesos official site ? there any good idea to do that ? >>> >>> Thanks very much. >>> >>> -- >>> Best Regards, >>> Chen, Qiang >>> >>> >> >> >> -- >> Best Regards, >> Haosdent Huang >> >> >> -- >> Best Regards, >> Chen, Qiang >> >> > > > -- > Best Regards, > Haosdent Huang > -- Deshi Xiao Twitter: xds2000 E-mail: xiaods(AT)gmail.com
