aurora-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sirois <jsir...@apache.org>
Subject Re: Review Request 45212: Remove hard dependency on a specific mesos-version
Date Thu, 24 Mar 2016 15:13:34 GMT


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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message