> On March 23, 2016, 3: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. > > 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. > > John Sirois wrote: > 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? > > Zameer Manji wrote: > I'm willing to move to the `>=` camp to be inline with the existing debs > and for the documentation to suggest X and X+1 are the suggested versions of > Mesos.
I am fine with `>=` as well. - Stephan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/45212/#review125027 ----------------------------------------------------------- On March 23, 2016, 3: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, 3: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 > >
