> On July 6, 2016, 8:33 p.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? > > Maxim Khutornenko wrote: > 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? > > Joshua Cohen wrote: > Yeah, we're going to have a similar issue for the 1.0 upgrade in that if > we operators opt in to GPU resources we're going to have to send a framework > capability that was only recently introduced.
I have 0 issues with certain releases violating a policy if well communicated. My concern was based off of 2 false premises: a non-existant +/- 1 policy and lack of commnication this would be a non -1 release. Thanks for setting me straight. - John ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/49732/#review141120 ----------------------------------------------------------- On July 6, 2016, 6:30 p.m., Maxim Khutornenko wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/49732/ > ----------------------------------------------------------- > > (Updated July 6, 2016, 6:30 p.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 > >
