I think we need a transition period when any kinks are worked out of 347 but I don't think we need one alpha/beta release where both mechanisms are supported (because 2246 was just a short term solution rather than a long term commitment). Ideally we'd get 347 in branch-2 for 2.0.4-beta and have that release to address issues that come up to fix for GA. Cloudera is actively testing 347 and parts of the community are eager to pick it up so I think that would work out timing wise. Reasonable?
On Mon, Feb 25, 2013 at 12:50 PM, Tsz Wo Sze <szets...@yahoo.com> wrote: > I agree that HDFS-2246 is a short term solution and we should not keep it > there forever. However, we still need a transition period to replace an old > mechanism by a new one. No? > > Tsz-Wo > > > > > ________________________________ > From: Eli Collins <e...@cloudera.com> > To: "hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org>; Tsz Wo Sze > <szets...@yahoo.com> > Sent: Monday, February 25, 2013 10:24 AM > Subject: Re: VOTE: HDFS-347 merge > > On Sat, Feb 23, 2013 at 4:23 PM, Tsz Wo Sze <szets...@yahoo.com> wrote: >> I still do not see a valid reason to remove HDFS-2246 immediately. Some >> users may have insecure clusters and they don't want to change their >> configuration. > > Because it doesn't make sense to support multiple mechanisms for the > same thing. > > 2246 was always intended to be a *short term solution* util 347 was > completed, eg see Sanjay's first comment on 2246: "A shortcut has > been proposed where the client access the hdfs file blocks directly... > This is non-invasive and is a good short term solution till HDFS-347 > is completed." > > Thanks, > Eli
