> 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
> 
>

Reply via email to