> On July 7, 2016, 2:33 a.m., John Sirois wrote:
> > I am slightly worried the tests only seem to work after this change ... 
> > IIUC Aurora 0.15.0 should work with mesos 0.27.2 (Aurora should work with 
> > the mesos its developed against +/- 1).
> 
> John Sirois wrote:
>     Oh, now I understand I think. You used this patch to do the 0.15.0 
> release, which is in error.  The 0.15.0 release should have a >= 0.27.2 mesos 
> constraint.
>     
>     If that makes sense, un-shipit.
> 
> Stephan Erb wrote:
>     That observation regarding specifying >=0.27 even though we have build 
> against 0.28 probably correct. 
>     
>     FWIW, our previous packages have been inconsistent in that regard as well:
>     
>     * 0.12 is build against Mesos 0.25 but specifies >=0.21.1 for Debian and 
> ==0.25 for Centos
>     * 0.13 is build against Mesos 0.26 but specifies >=0.26
>     * 0.14 is build against Mesos 0.27.2 but specifies >=0.27.2
> 
> Maxim Khutornenko wrote:
>     > Aurora should work with the mesos its developed against
>     
>     That may or may not be true. It all depends on what we change in Aurora 
> to bump up the Mesos version. In 0.15.0, we upgraded Mesos to 0.28.2 that 
> required us to treat the new Mesos task state (KILLING). This means 0.15.0 
> cannot rely on 0.27.2 anymore and >= 0.28.2 seems the only logical constraint 
> there.
> 
> Joshua Cohen wrote:
>     Yeah, unfortunately there's no great way to upgrade to 0.28.2 without 
> explicitly depending on the new `TaskState.KILLING` value. We either had to 
> make the change I made (add explicit support for the state to `Conversions` 
> or we would have had to update `ConversionsTest` to explicitly ignore that 
> task state, either way it would require 0.28.2. I suppose we *could* ignore 
> it in the test by checking for `"KILLING".equals(state.getName())`. That 
> seems a bit hacky but it would allow us to upgrade to 0.28.2 while letting 
> 0.15.0 still run against 0.27.x.
>     
>     Is that preferable, or are we ok with bending the rules in this instance?

I don't think we can shy away from the fact that Mesos upgrades may and will 
require making backwards incompatible Aurora changes as far as Mesos versions 
go. The whole purpose of supporting the ">=" syntax is to define the cluster 
upgrade as "first, upgrade Mesos then - Aurora". Trying to support -1 version 
in addition to +1 will only make our lifes harder and may even be impossible in 
the future (e.g.: switching from `launchTasks` to `acceptOffers`)

John, given the above, how would like to proceed with this patch?


- Maxim


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/49732/#review141120
-----------------------------------------------------------


On July 7, 2016, 12:30 a.m., Maxim Khutornenko wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/49732/
> -----------------------------------------------------------
> 
> (Updated July 7, 2016, 12:30 a.m.)
> 
> 
> Review request for Aurora and Stephan Erb.
> 
> 
> Repository: aurora-packaging
> 
> 
> Description
> -------
> 
> Update package scripts to 0.15.0.
> 
> 
> Diffs
> -----
> 
>   README.md 3a7cf45034b7896c23588fed83176468ca627ebc 
>   specs/debian/control e4d23ba6190ebbd3afbb930e305d76f5b61a5dac 
>   specs/rpm/aurora.spec 7a368fd8128153a3167032727fe011a8a7457853 
>   test/deb/debian-jessie/README.md a98407b96c673eb6ca6269d646755926d51fd4ab 
>   test/deb/debian-jessie/provision.sh 
> ed4364f69a63493d7a1fd6791ef743609c99b924 
>   test/deb/ubuntu-trusty/README.md c5579857443c73d8343a82210e34be98ad3a86da 
>   test/deb/ubuntu-trusty/provision.sh 
> 5b4ec472a23d5d401a64a6a72743c392d048f949 
>   test/rpm/centos-7/README.md e5649015934e4714a054a5be7a83f9c333b70144 
>   test/rpm/centos-7/provision.sh 5aa88a5d86a990131cdbdae5d93aeb75a1dc7c90 
> 
> Diff: https://reviews.apache.org/r/49732/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Maxim Khutornenko
> 
>

Reply via email to