>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
