> On March 23, 2016, 7:31 a.m., Stephan Erb wrote: > > Thinking out loud here, so please comment: > > > > We could move to a mode where we build against a specific Mesos version, > > and recommend that version for deployment, but leave it up to the cluster > > operator to select and deploy a compatible Mesos version. > > > > This would enable the following usecase: > > > > * Aurora 0.12 currently depends on Mesos 0.25 > > * By the given compatability, cluster operators can safely update to Mesos > > 0.26. > > * Instead of releasing Aurora with Mesos 0.26 as currently planned, we > > release a version build against 0.27. This one will be backwards > > compatible, and will therefore work with the deployed Mesos 0.26. > > * Cluster operators can then safely update to Mesos 0.27 and Mesos 0.28 > > > > This should make it easier for us to keep up with the Mesos release train... > > John Sirois wrote: > Leaving off the package dependency (which we already do by mistake for > the aurora-executor deb) certainly has a maintenance appeal, since we already > need to maintain the install guide in the aurora repo, which could contain or > point to a compatibility matrix we maintain. If we do go with no explicit > mesos dependency in our binary packages (or a floating one), I think its > important a compatibility matrix be prominent in the install docs since the > questions and install problems will happen. But if we do maintain a > compatibility matrix we could ~just as easily be adding the compatibility > constraints into the package dependencies too and avoiding a wider swath of > bug reports / questions. > > I've widened the reviewer scope a bit to gather more opions here. This > may need a dev@ thread. > > Stephan Erb wrote: > It's not a real bug for the executor. For the executor we boundle the > `mesos.native` wheel in the pex-file. > > Bill Farner wrote: > I'm pro min-version. Without true semantic versioning in mesos, i'm > doubtful we could be accurate with an upper bound.
I am pro min and max version. I believe the range that John proposes above is the best way to go. Mesos only guarantees -1/+1 and we should reflect that in the packaging. In my experience I have been bit by incompatabilities that can exist beyond +1/-1 and they were very difficult to debug. A more sophisticated cluster operator that knows what they are doing can use the facilities of rpm/deb to force a version of the package beyond our constraints if neeed. I'm not in favor of a compatability matrix, it seems like it would be a lot of work to maintain and test out, I suggest just rolling with what the Mesos project recomends until a better story comes out. - Zameer ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/45212/#review125027 ----------------------------------------------------------- On March 23, 2016, 7:56 a.m., Pierre Cheynier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/45212/ > ----------------------------------------------------------- > > (Updated March 23, 2016, 7:56 a.m.) > > > Review request for Aurora, Jake Farrell, John Sirois, Stephan Erb, Bill > Farner, and Zameer Manji. > > > Repository: aurora-packaging > > > Description > ------- > > We should consider MESOS_VERSION as the minimal requirement to install > the current Aurora version instead of enforce a specific Mesos version. > > > Diffs > ----- > > specs/rpm/aurora.spec 61e7d146108ae7dd5e129d8288a05773c2659d25 > > Diff: https://reviews.apache.org/r/45212/diff/ > > > Testing > ------- > > Install Aurora through the RPM built with aurora-packaging on a Mesos 0.27 > running install. > > > Thanks, > > Pierre Cheynier > >
