Sorry for ambiguity. Yes, we may deprecate now and remove in next major release.
On Mon, Feb 11, 2013 at 1:17 AM, Sandy Ryza <sandy.r...@cloudera.com> wrote: > If I understand correctly from searching for it in the code, while not > deprecated, the property currently has no effect. Does that not sound > right to you Harsh? > > Was there a conclusion on: may I deprecate it, or is there a larger > decision being waited on? > > -Sandy > > On Fri, Feb 8, 2013 at 9:35 PM, Harsh J <ha...@cloudera.com> wrote: > >> Yes, there isn't a "classic" version of mapreduce.framework.name now >> either. Its mostly being used as a pseudonym. MR1 no longer exists in >> 2.x releases/trunk. >> >> Note though that Oozie still relies on that specific property (JT >> address) and 0.22 clients may also perhaps be using it. We can >> deprecate it and remove on 3.x or later. >> >> On Sat, Feb 9, 2013 at 4:00 AM, Alejandro Abdelnur <t...@cloudera.com> >> wrote: >> > MR1 code is already gone from trunk and branch-2 >> > >> > Thx >> > >> > >> > On Fri, Feb 8, 2013 at 2:27 PM, Vinod Kumar Vavilapalli < >> > vino...@hortonworks.com> wrote: >> > >> >> >> >> There was a time when there were thoughts of being able to run MR1 in >> >> parallel with YARN while the later took off. So they were supposed to >> >> coexist, hence the non-deprecation. >> >> >> >> I am not sure we formally did, but once it is cast in stone that MR1 >> >> cannot be run with Hadoop 2.0 *(by which time we should remove JT/TT >> etc.), >> >> then we can deprecate these configs. >> >> >> >> Thanks, >> >> +Vinod >> >> >> >> On Feb 8, 2013, at 2:15 PM, Sandy Ryza wrote: >> >> >> >> > Is there a reason why mapreduce.jobtracker.address is not deprecated >> to >> >> > yarn.resourcemanager.address? >> >> > >> >> > thanks, >> >> > Sandy >> >> >> >> >> > >> > >> > -- >> > Alejandro >> >> >> >> -- >> Harsh J >> -- Harsh J
