> On March 23, 2016, 2:31 p.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. > > Zameer Manji wrote: > 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.
-1 to this patch. I don't see any real benefits here and certainly would not want to _guess_ the compat matrix. - Maxim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/45212/#review125027 ----------------------------------------------------------- On March 23, 2016, 2:56 p.m., Pierre Cheynier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/45212/ > ----------------------------------------------------------- > > (Updated March 23, 2016, 2:56 p.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 > >
