I haven't done it all at once because I haven't seen any demand for removing the 'host' attribute. If you (or other people) disagree, I can remove both special cases in one go.
On Mon, Oct 6, 2014 at 5:37 PM, Kevin Sweeney <kevi...@apache.org> wrote: > Why not take it all at once and avoid the need for 2 deprecation cycles? > With that change folks with existing Mesos clusters would be able to deploy > Aurora without changing the attributes flag on every slave (which requires > rebooting the entire cluster to take effect). > > On Mon, Oct 6, 2014 at 5:24 PM, Zameer Manji <zma...@twopensource.com> > wrote: > > > I currently don't plan on removing 'host' right now or in the future. If > > there is a need to remove it I would prefer to tackle it later. > > > > On Mon, Oct 6, 2014 at 5:13 PM, Kevin Sweeney <kevi...@apache.org> > wrote: > > > > > Will 'host' be deprecated as well? > > > > > > On Mon, Oct 6, 2014 at 4:30 PM, Zameer Manji <zma...@twopensource.com> > > > wrote: > > > > > > > I have put up a review <https://reviews.apache.org/r/26391/> which > > > removes > > > > the special casing and handling of the ‘rack’ constraint. This is a > > > > breaking change because Aurora will no longer inject a rack > constraint > > > of 1 > > > > if a job omits a rack constraint value. However this means that > Aurora > > > will > > > > be able to schedule jobs on to slaves which don’t have the ‘rack’ > > > attribute > > > > and slaves that want to accept tasks from Aurora don’t need to have > the > > > > ‘rack’ attribute set. > > > > > > > > Before the next release of Aurora (0.6.0) you should check if you are > > > > relying on the injected value for scheduling decisions and if so > > > explicitly > > > > encode a rack limit of 1 in the job's aurora config. > > > > > > > > -- > > > > Zameer Manji > > > > > > > > > > > > > > > -- > > Zameer Manji > > > -- Zameer Manji
