> On March 23, 2016, 8: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. > > 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. > > Maxim Khutornenko wrote: > -1 to this patch. I don't see any real benefits here and certainly would > not want to _guess_ the compat matrix. > > Pierre Cheynier wrote: > From my point of view, this compatibility (or at least approval) matrix > could be simply written in the release note at each release. > For ex: "0.12.0 supports only 0.25+ (enforced by constraint) and was > tested on: 0.25/0.26/0.27". > > No guarantee on the newer versions, but it avoid everyone that want to > test it to patch the aurora-packaging project. > > Operators on such big perimeters should be aware of the possible impacts > in upgrading one of the building block of their infrastructure.
I'll point out that Maxim's -1 implies a -1 to the existing deb packaging which uses >= instead of pinning like the rpms. OK - so we have absolutely no consensus fwict, but to move things forward, I'd like to see consistency in the version constraints across our binary packages and I think Pierre's matrix proposal is good enough to allay my fears of folks trying really new versions of mesos with older versions of aurora and expecting things to work. We could either use a matrix in the installing docs - which I still favor in Pierre's suggested format - or, if Zameer or others still find that to be too much overhead - I'd also be fine with static boilerplate text in installing docs that say tested with X, X+1 should work, for the rest you are on your own and extensive testing is reccomended before using the combination in prod. So the tally is: +3 >= (Pierre, Bill, John) +1 [no constraint] (Stephan) +1 >= <= (Zameer) +1 == (Maxim) Anyone else willing to compromise here? - John ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/45212/#review125027 ----------------------------------------------------------- On March 23, 2016, 8: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, 8: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 > >
