Re: Apache jenkins job to build release artifacts (WAS: Issue with my username on my company provided dev box?)
FWIW I've used a (local) VM for releases in the past, a VM with read-only access to the repository, that was never used for development -lets you lock down the box more -guarantees src is untainted by edits -lets you run a release build/test run within the VM while you are still coding, without any interference -lets you do an rm -rf ~/.m2 ~/.ivy before the build -lets people with windows desktops cut a release weaknesses? -Slower IO -All changes to things like release notes need to be done local & propagated via SVN -if you do want auto-publish via scp, VM needs your private key without a password. We created a special user @sourceforge for this -usual brittleness of a VM that is only used once every month to changes -after the yum update things may break, the wrong version of java creep in, etc. That has to be included in the schedule. -once you share the VMs by copying disk images the maintenance cost is O(VM-instances) -automated releases can get you complacent about shipping things without doing the full install tests (on other (clean) VMs) -when you did run the fully distributed test harness, it would certainly pick up on things like concurrency and network problems, but it did nothing to help you actually track down the issue ( http://sourceforge.net/p/smartfrog/svn/HEAD/tree/trunk/core/components/arithmetic-testharness/src/org/smartfrog/services/slp/ ) that release process in full: http://sourceforge.net/p/smartfrog/svn/HEAD/tree/trunk/core/release/doc/creating_release_artifacts.pdf?format=raw -Steve -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
[jira] [Resolved] (HDFS-5849) Removing ACL from an inode fails if it has only a default ACL.
[
https://issues.apache.org/jira/browse/HDFS-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Nauroth resolved HDFS-5849.
-
Resolution: Fixed
Fix Version/s: HDFS ACLs (HDFS-4685)
Hadoop Flags: Reviewed
Thanks for the review, Arpit. I committed this to the HDFS-4685 branch.
> Removing ACL from an inode fails if it has only a default ACL.
> --
>
> Key: HDFS-5849
> URL: https://issues.apache.org/jira/browse/HDFS-5849
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
>Affects Versions: HDFS ACLs (HDFS-4685)
>Reporter: Chris Nauroth
>Assignee: Chris Nauroth
> Fix For: HDFS ACLs (HDFS-4685)
>
> Attachments: HDFS-5849.1.patch
>
>
> When removing an ACL, the logic must restore the group permission previously
> stored in an ACL entry back into the group permission bits. The logic for
> this in {{AclTransformation#removeINodeAcl}} assumes that the group entry
> must be found in the former ACL. This is not the case when removing the ACL
> from an inode that only had a default ACL and not an access ACL.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
READY: Apache Jenkins job to create Hadoop 2.x release artifacts
*All,* The Apache Jenkins job to build release artifacts for Hadoop 2 is ready (in its first incarnation). The job URL is: https://builds.apache.org/job/HADOOP2_Release_Artifacts_Builder/ I hope this will make moot all concerns about user accounts and about the hardware ownership being used to generate Hadoop 2 release artifacts. *Andrew & Arun,* Because the two of you are driving/coordinating the release of Hadoop 2.3.0, you'll be the first ones to use the release script and job. If you run into any issues or you have ideas on how to improve it, please don't hesitate to let me know; I'll be more than happy to help. One thing I ask you both is to update the "How to Release" wiki page to reflect all necessary current steps to build a release, specially the manual steps. Having this up to date and complete will help others to take on the Release Manager tasks without being suck into a time sink. *Roman,* If Bigtop wants to consume release artifacts from this job on regular basis, we'll need to modify the job to run periodically. Fell free to do so, just make sure that when running because of a cron trigger the RC_LABEL used states so, i.e.: NIGHTLY. And all the produced artifacts will be labeled with it. Also, if for Bigtop is more convenient to have artifacts without SNAPSHOT JARs even if the Hadoop POMs still have SNAPSHOT in the branch, I have an idea on how we could do that (doing a build with an additional patch -being fetched- on top of the branch). Thanks and cheers to all. -- Alejandro
[jira] [Resolved] (HDFS-5811) TestHDFSCLI fails for a user name with dash
[
https://issues.apache.org/jira/browse/HDFS-5811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gera Shegalov resolved HDFS-5811.
-
Resolution: Duplicate
ASF JIRA was flaky and created duplicates while reporting an error to the
frontend.
> TestHDFSCLI fails for a user name with dash
> ---
>
> Key: HDFS-5811
> URL: https://issues.apache.org/jira/browse/HDFS-5811
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: test
>Affects Versions: 2.2.0
>Reporter: Gera Shegalov
>
> testHDFSConf.xml uses a regex to describe username. Regexes are used
> incosistently from {code}[a-zA-z0-9]*{code} to {code}[a-z]*{code}. Clearly OS
> are less restrictive than that, and for us specifically the test fails for a
> build user having a {code}-{code}. So instead of keeping updating regex, I
> propose to replace it with the macro USERNAME.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (HDFS-5812) TestHDFSCLI fails for a user name with dash
[
https://issues.apache.org/jira/browse/HDFS-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gera Shegalov resolved HDFS-5812.
-
Resolution: Duplicate
ASF JIRA was flaky and created duplicates while reporting an error to the
frontend.
> TestHDFSCLI fails for a user name with dash
> ---
>
> Key: HDFS-5812
> URL: https://issues.apache.org/jira/browse/HDFS-5812
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: test
>Affects Versions: 2.2.0
>Reporter: Gera Shegalov
>
> testHDFSConf.xml uses a regex to describe username. Regexes are used
> incosistently from {code}[a-zA-z0-9]*{code} to {code}[a-z]*{code}. Clearly OS
> are less restrictive than that, and for us specifically the test fails for a
> build user having a {code}-{code}. So instead of keeping updating regex, I
> propose to replace it with the macro USERNAME.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (HDFS-5816) TestHDFSCLI fails for a user name with dash
[
https://issues.apache.org/jira/browse/HDFS-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gera Shegalov resolved HDFS-5816.
-
Resolution: Duplicate
ASF JIRA was flaky and created duplicates while reporting an error to the
frontend.
> TestHDFSCLI fails for a user name with dash
> ---
>
> Key: HDFS-5816
> URL: https://issues.apache.org/jira/browse/HDFS-5816
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: test
>Affects Versions: 2.2.0
>Reporter: Gera Shegalov
>
> testHDFSConf.xml uses a regex to describe username. Regexes are used
> incosistently from {code}[a-zA-z0-9]*{code} to {code}[a-z]*{code}. Clearly OS
> are less restrictive than that, and for us specifically the test fails for a
> build user having a {{-}}. So instead of keeping updating regex, I propose to
> replace it with the macro USERNAME.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (HDFS-5817) TestHDFSCLI fails for a user name with dash
[
https://issues.apache.org/jira/browse/HDFS-5817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gera Shegalov resolved HDFS-5817.
-
Resolution: Duplicate
ASF JIRA was flaky and created duplicates while reporting an error to the
frontend.
> TestHDFSCLI fails for a user name with dash
> ---
>
> Key: HDFS-5817
> URL: https://issues.apache.org/jira/browse/HDFS-5817
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: test
>Affects Versions: 2.2.0
>Reporter: Gera Shegalov
>
> testHDFSConf.xml uses a regex to describe username. Regexes are used
> incosistently from {code}[a-zA-z0-9]*{code} to {code}[a-z]*{code}. Clearly OS
> are less restrictive than that, and for us specifically the test fails for a
> build user having a {{-}}. So instead of keeping updating regex, I propose to
> replace it with the macro USERNAME.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (HDFS-5859) DataNode#checkBlockToken should check block tokens even if security is not enabled
Colin Patrick McCabe created HDFS-5859: -- Summary: DataNode#checkBlockToken should check block tokens even if security is not enabled Key: HDFS-5859 URL: https://issues.apache.org/jira/browse/HDFS-5859 Project: Hadoop HDFS Issue Type: Bug Components: datanode Affects Versions: 2.4.0 Reporter: Colin Patrick McCabe Assignee: Colin Patrick McCabe DataNode#checkBlockToken should check block tokens even if security is not enabled, so that unit tests that turn on block tokens (but not security) can get an effective test. This is only for unit tests. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (HDFS-5819) TestHDFSCLI fails for a user name with dash
[
https://issues.apache.org/jira/browse/HDFS-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gera Shegalov resolved HDFS-5819.
-
Resolution: Duplicate
ASF JIRA was flaky and created duplicates while reporting an error to the
frontend.
> TestHDFSCLI fails for a user name with dash
> ---
>
> Key: HDFS-5819
> URL: https://issues.apache.org/jira/browse/HDFS-5819
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: test
>Affects Versions: 2.2.0
>Reporter: Gera Shegalov
>
> testHDFSConf.xml uses a regex to describe username. Regexes are used
> incosistently from {code}[a-zA-z0-9]*{code} to {code}[a-z]*{code}. Clearly OS
> are less restrictive than that, and for us specifically the test fails for a
> build user having a {{-}}. So instead of keeping updating regex, I propose to
> replace it with the macro USERNAME.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (HDFS-5818) TestHDFSCLI fails for a user name with dash
[
https://issues.apache.org/jira/browse/HDFS-5818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gera Shegalov resolved HDFS-5818.
-
Resolution: Duplicate
ASF JIRA was flaky and created duplicates while reporting an error to the
frontend.
> TestHDFSCLI fails for a user name with dash
> ---
>
> Key: HDFS-5818
> URL: https://issues.apache.org/jira/browse/HDFS-5818
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: test
>Affects Versions: 2.2.0
>Reporter: Gera Shegalov
>
> testHDFSConf.xml uses a regex to describe username. Regexes are used
> incosistently from {code}[a-zA-z0-9]*{code} to {code}[a-z]*{code}. Clearly OS
> are less restrictive than that, and for us specifically the test fails for a
> build user having a {{-}}. So instead of keeping updating regex, I propose to
> replace it with the macro USERNAME.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
Re: [VOTE] Merge HDFS-5698 Use protobuf to serialize / deserialize FSImage to trunk
+1. This is an important feature that gets rid of all the custom serialization and unnecessary code around it. Helps in rolling upgrade scenarios too! Nice job Haohui Mai and Jing Zhao! On Thu, Jan 30, 2014 at 2:37 PM, Haohui Mai wrote: > Hello all, > > I would like to call a vote to merge of the new protobuf-based FSImage into > trunk. > > The changes introduce a protobuf-based FSImage format into HDFS. It > separates the responsibility of serializing and reconstructing the > namespace in the NameNode using Google's Protocol Buffers > (protobuf). The new FSImage delegates much parts of the serialization / > deserialization logics to the protobuf side. It is also designed to > improve the supports for compatibility and interoperability. > > The development has been done in a separate branch: > https://svn.apache.org/repos/asf/hadoop/common/branches/HDFS-5698 > > The design document is available at: > > https://issues.apache.org/jira/secure/attachment/12626179/HDFS-5698-design.pdf > > The HDFS-5698 jira tracks the development of the feature. > > The feature changes no public APIs. The existing tests include both > unit tests and end-to-end tests. They have already covered this > feature. > > Once the feature is merged into trunk, we will continue to test and > fix any bugs that may be found on trunk. > > The bulk of the design and implementation was done by Jing Zhao, > Suresh Srinivas and me. Thanks Kihwal Lee, Todd Lipcon, Colin > Patrick McCabe, Chris Nauroth, and Daryn Sharp for providing feedback on > the jiras and in discussions. > > This vote runs for a week and closes on 2/6/2013 at 11:59 pm PT. > > Regards, > Haohui > > -- > CONFIDENTIALITY NOTICE > NOTICE: This message is intended for the use of the individual or entity to > which it is addressed and may contain information that is confidential, > privileged and exempt from disclosure under applicable law. If the reader > of this message is not the intended recipient, you are hereby notified that > any printing, copying, dissemination, distribution, disclosure or > forwarding of this communication is strictly prohibited. If you have > received this communication in error, please contact the sender immediately > and delete it from your system. Thank You. > -- http://hortonworks.com/download/ -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
[jira] [Created] (HDFS-5860) Refactor INodeDirectory getDirectoryXFeature methods to use common getFeature helper method.
Chris Nauroth created HDFS-5860:
---
Summary: Refactor INodeDirectory getDirectoryXFeature methods to
use common getFeature helper method.
Key: HDFS-5860
URL: https://issues.apache.org/jira/browse/HDFS-5860
Project: Hadoop HDFS
Issue Type: Improvement
Components: namenode
Affects Versions: HDFS ACLs (HDFS-4685)
Reporter: Chris Nauroth
Priority: Minor
The HDFS-4685 feature branch has introduced a helper method for getting an
inode feature of a particular class: {{INodeWithAdditionalFields#getFeature}}.
Currently, this is only called by code related to ACLs, but we can also use the
same method to reduce code duplication in the various {{INodeDirectory}}
methods that get different kinds of features.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (HDFS-5614) NameNode: implement handling of ACLs in combination with snapshots.
[ https://issues.apache.org/jira/browse/HDFS-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Nauroth resolved HDFS-5614. - Resolution: Fixed Fix Version/s: HDFS ACLs (HDFS-4685) Hadoop Flags: Reviewed I committed this to the HDFS-4685 branch. Thanks again to Jing for the code review. > NameNode: implement handling of ACLs in combination with snapshots. > --- > > Key: HDFS-5614 > URL: https://issues.apache.org/jira/browse/HDFS-5614 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: namenode >Affects Versions: HDFS ACLs (HDFS-4685) >Reporter: Chris Nauroth >Assignee: Chris Nauroth > Fix For: HDFS ACLs (HDFS-4685) > > Attachments: HDFS-5614.1.patch, HDFS-5614.2.patch, HDFS-5614.3.patch > > > Within a snapshot, all ACLs are frozen at the moment that the snapshot was > created. ACL changes in the parent of the snapshot are not applied to the > snapshot. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (HDFS-5858) Refactor common ACL test cases to be run through multiple FileSystem implementations.
[
https://issues.apache.org/jira/browse/HDFS-5858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Nauroth resolved HDFS-5858.
-
Resolution: Fixed
Hadoop Flags: Reviewed
Thanks once again, Arpit. I committed this to the HDFS-4685 branch.
> Refactor common ACL test cases to be run through multiple FileSystem
> implementations.
> -
>
> Key: HDFS-5858
> URL: https://issues.apache.org/jira/browse/HDFS-5858
> Project: Hadoop HDFS
> Issue Type: Test
> Components: namenode, test, webhdfs
>Affects Versions: HDFS ACLs (HDFS-4685)
>Reporter: Chris Nauroth
>Assignee: Chris Nauroth
>Priority: Minor
> Attachments: HDFS-5858.1.patch, HDFS-5858.2.patch
>
>
> HDFS-5608 implemented WebHDFS bindings for the new ACL APIs. As part of that
> patch, the test cases implemented in {{TestNameNodeAcl}} were duplicated to
> be run through {{WebHdfsFileSystem}}. Instead of duplicating, we can
> refactor so that the test cases are defined in a shared base class, and
> individual test suite subclasses initialize a different {{FileSystem}}
> implementation for those test cases to use.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
Re: Re-swizzle 2.3
Thanks Vinod, appreciate it! I think we are very close. Here is a handy ref. to the list of blockers: http://s.apache.org/hadoop-2.3.0-blockers I'd appreciate if folks can help expedite these fixes, and, equally importantly bring up others they feel should be blockers for 2.3.0. thanks, Arun On Jan 30, 2014, at 12:42 PM, Vinod Kumar Vavilapalli wrote: > That was quite some exercise, but I'm done with it now. Updated YARN's and > MAPREDUCE's CHANGES.txt on trunk, branch-2 and branch-2.3. Let me know if you > find some inaccuracies. > > Thanks, > +Vinod > > On Jan 29, 2014, at 10:49 PM, Vinod Kumar Vavilapalli > wrote: > >> >> Okay, I'll look at YARN and MR CHANGES.txt problems. Seems like they aren't >> addressed yet. >> >> +Vinod >> >> >> On Jan 29, 2014, at 3:24 PM, Andrew Wang 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 wrote: On Wed, Jan 29, 2014 at 12:30 PM, Jason Lowe 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 >> > > > -- > CONFIDENTIALITY NOTICE > NOTICE: This message is intended for the use of the individual or entity to > which it is addressed and may contain information that is confidential, > privileged and exempt from disclosure under applicable law. If the reader > of this message is not the intended recipient, you are hereby notified that > any printing, copying, dissemination, distribution, disclosure or > forwarding of this communication is strictly prohibited. If you have > received this communication in error, please contact the sender immediately > and delete it from your system. Thank You. > -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/ -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: Re-swizzle 2.3
Thanks for the link Arun, I went ahead and punted one HADOOP blocker, and the remaining two HADOOP/HDFS looks like they're under active review. Post-swizzle, it seems like most blockers for 2.4 would also apply to 2.3, so I looked at that list too: https://issues.apache.org/jira/issues/?filter=12326375&jql=project%20in%20(HADOOP%2C%20YARN%2C%20HDFS%2C%20MAPREDUCE)%20AND%20priority%20%3D%20Blocker%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20%22Patch%20Available%22)%20AND%20%22Target%20Version%2Fs%22%20%3D%20%222.4.0%22 YARN-1673 IIUC relates to the AHS, so is actually only in branch-2 and not branch-2.3. HADOOP-10048, Jason's comment says he's okay with it not being a blocker. HDFS-5796 hasn't seen much action. Kihwal or Haohui, could you comment on the importance/status? I don't have much context in this area. Best, Andrew On Fri, Jan 31, 2014 at 4:29 PM, Arun C Murthy wrote: > Thanks Vinod, appreciate it! > > I think we are very close. > > Here is a handy ref. to the list of blockers: > http://s.apache.org/hadoop-2.3.0-blockers > > I'd appreciate if folks can help expedite these fixes, and, equally > importantly bring up others they feel should be blockers for 2.3.0. > > thanks, > Arun > > On Jan 30, 2014, at 12:42 PM, Vinod Kumar Vavilapalli > wrote: > > > That was quite some exercise, but I'm done with it now. Updated YARN's > and MAPREDUCE's CHANGES.txt on trunk, branch-2 and branch-2.3. Let me know > if you find some inaccuracies. > > > > Thanks, > > +Vinod > > > > On Jan 29, 2014, at 10:49 PM, Vinod Kumar Vavilapalli < > vino...@apache.org> wrote: > > > >> > >> Okay, I'll look at YARN and MR CHANGES.txt problems. Seems like they > aren't addressed yet. > >> > >> +Vinod > >> > >> > >> On Jan 29, 2014, at 3:24 PM, Andrew Wang > 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 > wrote: > > On Wed, Jan 29, 2014 at 12:30 PM, Jason Lowe > 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 > >> > > > > > > -- > > CONFIDENTIALITY NOTICE > > NOTICE: This message is intended for the use of the individual or entity > to > > which it is addressed and may contain information that is confidential, > > privileged and exempt from disclosure under applicable law. If the reader > > of this message is not the intended recipient, you are hereby notified > that > > any printing, copying, dissemination, distribution, disclosure or > > forwarding of this communication is strictly prohibited. If you have > > received this communication in error, please contact the sender > immediately > > and delete it from your system. Thank You. > > > > -- > Arun C. Murthy > Hortonworks Inc. > http://hortonworks.com/ > > > > -- > CONFIDENTIALITY NOTICE > NOTICE: This message is intended for the use of the individual or entity to > which it is addressed and may contain information that is confidential, > privileged and exempt from disclosure under applicable law. If the reader > of this message is not the intended recipient, you are hereby notified that > any printing, copying, dissemination, distribution, disclosure or > forwarding of this communication is strictly prohibited. If you have > received this communication in error, please contact the sender immediately > and delete it from your system. Thank You. >
[jira] [Created] (HDFS-5861) Add CLI test for Ls output for extended ACL marker
Vinay created HDFS-5861: --- Summary: Add CLI test for Ls output for extended ACL marker Key: HDFS-5861 URL: https://issues.apache.org/jira/browse/HDFS-5861 Project: Hadoop HDFS Issue Type: Sub-task Reporter: Vinay Assignee: Vinay Add a xml test to aclTestCLI.xml to test the output of the LS command for the extended ACL file/dir. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (HDFS-5860) Refactor INodeDirectory getDirectoryXFeature methods to use common getFeature helper method.
[
https://issues.apache.org/jira/browse/HDFS-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Nauroth resolved HDFS-5860.
-
Resolution: Fixed
Fix Version/s: HDFS ACLs (HDFS-4685)
Hadoop Flags: Reviewed
+1 for the patch. I committed it to the HDFS-4685 feature branch. Thanks for
taking care of this so quickly, Jing.
> Refactor INodeDirectory getDirectoryXFeature methods to use common getFeature
> helper method.
>
>
> Key: HDFS-5860
> URL: https://issues.apache.org/jira/browse/HDFS-5860
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: namenode
>Affects Versions: HDFS ACLs (HDFS-4685)
>Reporter: Chris Nauroth
>Assignee: Jing Zhao
>Priority: Minor
> Fix For: HDFS ACLs (HDFS-4685)
>
> Attachments: HDFS-5860.000.patch
>
>
> The HDFS-4685 feature branch has introduced a helper method for getting an
> inode feature of a particular class:
> {{INodeWithAdditionalFields#getFeature}}. Currently, this is only called by
> code related to ACLs, but we can also use the same method to reduce code
> duplication in the various {{INodeDirectory}} methods that get different
> kinds of features.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (HDFS-5861) Add CLI test for Ls output for extended ACL marker
[ https://issues.apache.org/jira/browse/HDFS-5861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Nauroth resolved HDFS-5861. - Resolution: Fixed Hadoop Flags: Reviewed +1 for the patch. I verified the test, and I committed it to the HDFS-4685 feature branch. Vinay, thank you for adding this test. > Add CLI test for Ls output for extended ACL marker > -- > > Key: HDFS-5861 > URL: https://issues.apache.org/jira/browse/HDFS-5861 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: hdfs-client, namenode, security >Affects Versions: HDFS ACLs (HDFS-4685) >Reporter: Vinay >Assignee: Vinay > Attachments: HDFS-5861.patch > > > Add a xml test to aclTestCLI.xml to test the output of the LS command for the > extended ACL file/dir. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
