hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron T. Myers" <...@cloudera.com>
Subject Re: Re-swizzle 2.3
Date Thu, 30 Jan 2014 16:02:51 GMT
I just committed HADOOP-10310 to branch-2.3, so we're good to go there.
(Thanks to Andrew and Daryn for the prompt reviews.)

--
Aaron T. Myers
Software Engineer, Cloudera


On Wed, Jan 29, 2014 at 6:52 PM, Aaron T. Myers <atm@cloudera.com> wrote:

> I just filed this JIRA as a blocker for 2.3:
> https://issues.apache.org/jira/browse/HADOOP-10310
>
> The tl;dr is that JNs will not work with security enabled without this
> fix. If others don't think that supporting QJM with security enabled
> warrants a blocker for 2.3, then we can certainly lower the priority, but
> it seems pretty important to me.
>
> Best,
> Aaron
>
> --
> Aaron T. Myers
> Software Engineer, Cloudera
>
>
> On Wed, Jan 29, 2014 at 6:24 PM, Andrew Wang <andrew.wang@cloudera.com>wrote:
>
>> I just finished tuning up branch-2.3 and fixing up the HDFS and Common
>> CHANGES.txt in trunk, branch-2, and branch-2.3. I had to merge back a few
>> JIRAs committed between the swizzle and now where the fix version was 2.3
>> but weren't in branch-2.3.
>>
>> I think the only two HDFS and Common JIRAs that are marked for 2.4 are
>> these:
>>
>> HDFS-5842 Cannot create hftp filesystem when using a proxy user ugi and a
>> doAs on a secure cluster
>> HDFS-5781 Use an array to record the mapping between FSEditLogOpCode and
>> the corresponding byte value
>>
>> Jing, these both look safe to me if you want to merge them back, or I can
>> just do it.
>>
>> Thanks,
>> Andrew
>>
>> On Wed, Jan 29, 2014 at 1:21 PM, Doug Cutting <cutting@apache.org> wrote:
>> >
>> > On Wed, Jan 29, 2014 at 12:30 PM, Jason Lowe <jlowe@yahoo-inc.com>
>> wrote:
>> > >  It is a bit concerning that the JIRA history showed that the target
>> version
>> > > was set at some point in the past but no record of it being cleared.
>> >
>> > Perhaps the version itself was renamed?
>> >
>> > Doug
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message