[jira] [Commented] (ATLAS-659) atlas_start fails on Windows

2016-04-29 Thread ATLAS QA (JIRA) 

[ 
https://issues.apache.org/jira/browse/ATLAS-659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15265042#comment-15265042
 ] 

ATLAS QA commented on ATLAS-659:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment
  http://issues.apache.org/jira/secure/attachment/12801566/rb46444.patch
  against master revision 7d040c5.

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 1 new 
or modified test files.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javadoc{color}.  There were no new javadoc warning messages.

+1 checkstyle.  The patch generated 0 code style errors.

{color:red}-1 findbugs{color}.  The patch appears to introduce 361 new 
Findbugs (version 2.0.3) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:red}-1 core tests{color}.  The patch failed these unit tests in :
 
./webapp/test-output/junitreports/TEST-org.apache.atlas.web.resources.RexsterGraphJerseyResourceIT
./webapp/test-output/junitreports/TEST-org.apache.atlas.web.resources.AdminJerseyResourceIT
./webapp/test-output/junitreports/TEST-org.apache.atlas.web.resources.EntityJerseyResourceIT
./webapp/test-output/junitreports/TEST-org.apache.atlas.web.resources.MetadataDiscoveryJerseyResourceIT
./webapp/test-output/junitreports/TEST-org.apache.atlas.web.resources.TypesJerseyResourceIT

Test results: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/191//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/191//artifact/patchprocess/newPatchFindbugsWarningswebapp.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/191//artifact/patchprocess/newPatchFindbugsWarningscommon.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/191//artifact/patchprocess/newPatchFindbugsWarningssqoop-bridge.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/191//artifact/patchprocess/newPatchFindbugsWarningshdfs-model.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/191//artifact/patchprocess/newPatchFindbugsWarningsstorm-bridge.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/191//artifact/patchprocess/newPatchFindbugsWarningshive-bridge.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/191//artifact/patchprocess/newPatchFindbugsWarningsrepository.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/191//artifact/patchprocess/newPatchFindbugsWarningstypesystem.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/191//artifact/patchprocess/newPatchFindbugsWarningsclient.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/191//artifact/patchprocess/newPatchFindbugsWarningsnotification.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/191//artifact/patchprocess/newPatchFindbugsWarningstitan.html
Console output: https://builds.apache.org/job/PreCommit-ATLAS-Build/191//console

This message is automatically generated.

> atlas_start fails on Windows
> 
>
> Key: ATLAS-659
> URL: https://issues.apache.org/jira/browse/ATLAS-659
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Kantor
>Assignee: David Kantor
>Priority: Blocker
> Attachments: rb46444.patch
>
>
> Recent changes for using HBase as the default storage backend has broken 
> Atlas startup on Windows, which now fails with:
> {noformat}
> Exception: [Error 193] %1 is not a valid Win32 application
> Traceback (most recent call last):
>   File "atlas_start.py", line 113, in 
> returncode = main()
>   File "atlas_start.py", line 68, in main
> mc.run_hbase(mc.hbaseBinDir(atlas_home), "start", hbase_conf_dir, 
> logdir)
>   File 
> "C:\OMS_main1\oms\atlas\distro\target\atlas\distro\target\apache-atlas-0.7-incubating-SNAPSHOT-bin\apache-atlas-0.7-incubating-SNAPSHOT\bin\atlas_config.py",
>  
> line 365, in run_hbase
> return runProcess(cmd, logdir, False, wait)
>   File 
> "C:\OMS_main1\oms\atlas\distro\target\atlas\distro\target\apache-atlas-0.7-incubating-SNAPSHOT-bin\apache-atlas-0.7-incubating-SNAPSHOT\bin\atlas_config.py",
>  line 194, in runProcess
> p = subprocess.Popen(commandline, stdout=stdoutFile, stderr=stderrFile, 
> shell=shell)
>   File "C:\Python27\lib\subprocess.py", line 710, in __init__
> errread, errwrite)
>   File "C:\Python27\lib\subprocess.py", line 958, in _execute_child
> startupinfo)
> WindowsError: [Error 193] %1 is not a valid Win32 application
> {noformat}



--
This

[jira] [Updated] (ATLAS-659) atlas_start fails on Windows

2016-04-29 Thread David Kantor (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ATLAS-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Kantor updated ATLAS-659:
---
Attachment: rb46444.patch

> atlas_start fails on Windows
> 
>
> Key: ATLAS-659
> URL: https://issues.apache.org/jira/browse/ATLAS-659
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Kantor
>Assignee: David Kantor
>Priority: Blocker
> Attachments: rb46444.patch
>
>
> Recent changes for using HBase as the default storage backend has broken 
> Atlas startup on Windows, which now fails with:
> {noformat}
> Exception: [Error 193] %1 is not a valid Win32 application
> Traceback (most recent call last):
>   File "atlas_start.py", line 113, in 
> returncode = main()
>   File "atlas_start.py", line 68, in main
> mc.run_hbase(mc.hbaseBinDir(atlas_home), "start", hbase_conf_dir, 
> logdir)
>   File 
> "C:\OMS_main1\oms\atlas\distro\target\atlas\distro\target\apache-atlas-0.7-incubating-SNAPSHOT-bin\apache-atlas-0.7-incubating-SNAPSHOT\bin\atlas_config.py",
>  
> line 365, in run_hbase
> return runProcess(cmd, logdir, False, wait)
>   File 
> "C:\OMS_main1\oms\atlas\distro\target\atlas\distro\target\apache-atlas-0.7-incubating-SNAPSHOT-bin\apache-atlas-0.7-incubating-SNAPSHOT\bin\atlas_config.py",
>  line 194, in runProcess
> p = subprocess.Popen(commandline, stdout=stdoutFile, stderr=stderrFile, 
> shell=shell)
>   File "C:\Python27\lib\subprocess.py", line 710, in __init__
> errread, errwrite)
>   File "C:\Python27\lib\subprocess.py", line 958, in _execute_child
> startupinfo)
> WindowsError: [Error 193] %1 is not a valid Win32 application
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 46444: ATLAS-659: Fix issues with using embedded HBase on Windows

2016-04-29 Thread David Kantor 


> On April 21, 2016, 7:24 p.m., Neeru Gupta wrote:
> > distro/src/bin/atlas_config.py, line 360
> > 
> >
> > It looks like this method either starts the hbase or stops it. Should 
> > this be renamed to startStopHbase inplace of runHbase.

Renamed the method to run_hbase_action


- David


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46444/#review129941
---


On April 30, 2016, 12:04 a.m., David Kantor wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46444/
> ---
> 
> (Updated April 30, 2016, 12:04 a.m.)
> 
> 
> Review request for atlas.
> 
> 
> Bugs: ATLAS-659
> https://issues.apache.org/jira/browse/ATLAS-659
> 
> 
> Repository: atlas
> 
> 
> Description
> ---
> 
> ATLAS-659: Fix issues with using embedded HBase on Windows so that HBase 
> successfully starts and stops as part of Atlas startup/shutdown.
> - Use correct HBase start and stop scripts for Windows
> - Start HBase server after checking existing Atlas server
> - Use Windows-specific template for hbase-site.xml - file URL for 
> hbase.rootdir needs three slashes to avoid error: "Illegal character in 
> authority at index 5"
> - In TestMetadata.py, check mock for HBase Windows startup script
> 
> 
> Diffs
> -
> 
>   distro/src/bin/atlas_config.py 2b6bc825858cc5b36d55cba5b85b2087e8b4ecfe 
>   distro/src/bin/atlas_start.py 4199e372c1357e490171fb1c9328c7529dbe0492 
>   distro/src/bin/atlas_stop.py 5653244cff141b9e9fd68cf6877c4d6ec952ee0f 
>   distro/src/conf/hbase/windows-hbase-site.xml.template PRE-CREATION 
>   distro/src/test/python/scripts/TestMetadata.py 
> bb74f2004501473fc726fe58e8f9ad1ead3e18f1 
> 
> Diff: https://reviews.apache.org/r/46444/diff/
> 
> 
> Testing
> ---
> 
> Ran all unit and integration tests with no regressions.
> 
> 
> Thanks,
> 
> David Kantor
> 
>

Re: Review Request 46444: ATLAS-659: Fix issues with using embedded HBase on Windows

2016-04-29 Thread David Kantor 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46444/
---

(Updated April 30, 2016, 12:04 a.m.)


Review request for atlas.


Changes
---

Addressed Neeru's comment


Bugs: ATLAS-659
https://issues.apache.org/jira/browse/ATLAS-659


Repository: atlas


Description
---

ATLAS-659: Fix issues with using embedded HBase on Windows so that HBase 
successfully starts and stops as part of Atlas startup/shutdown.
- Use correct HBase start and stop scripts for Windows
- Start HBase server after checking existing Atlas server
- Use Windows-specific template for hbase-site.xml - file URL for hbase.rootdir 
needs three slashes to avoid error: "Illegal character in authority at index 5"
- In TestMetadata.py, check mock for HBase Windows startup script


Diffs (updated)
-

  distro/src/bin/atlas_config.py 2b6bc825858cc5b36d55cba5b85b2087e8b4ecfe 
  distro/src/bin/atlas_start.py 4199e372c1357e490171fb1c9328c7529dbe0492 
  distro/src/bin/atlas_stop.py 5653244cff141b9e9fd68cf6877c4d6ec952ee0f 
  distro/src/conf/hbase/windows-hbase-site.xml.template PRE-CREATION 
  distro/src/test/python/scripts/TestMetadata.py 
bb74f2004501473fc726fe58e8f9ad1ead3e18f1 

Diff: https://reviews.apache.org/r/46444/diff/


Testing
---

Ran all unit and integration tests with no regressions.


Thanks,

David Kantor

[jira] [Commented] (ATLAS-645) FieldMapping.output() results in stack overflow when instances reference each other

2016-04-29 Thread ATLAS QA (JIRA) 

[ 
https://issues.apache.org/jira/browse/ATLAS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15264957#comment-15264957
 ] 

ATLAS QA commented on ATLAS-645:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment
  http://issues.apache.org/jira/secure/attachment/12801540/rb45948.patch
  against master revision 7d040c5.

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 1 new 
or modified test files.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javadoc{color}.  There were no new javadoc warning messages.

+1 checkstyle.  The patch generated 0 code style errors.

{color:red}-1 findbugs{color}.  The patch appears to introduce 361 new 
Findbugs (version 2.0.3) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:red}-1 core tests{color}.  The patch failed these unit tests in :
   
org.apache.atlas.repository.typestore.GraphBackedTypeStoreTest

Test results: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/190//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/190//artifact/patchprocess/newPatchFindbugsWarningscommon.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/190//artifact/patchprocess/newPatchFindbugsWarningshive-bridge.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/190//artifact/patchprocess/newPatchFindbugsWarningshdfs-model.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/190//artifact/patchprocess/newPatchFindbugsWarningssqoop-bridge.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/190//artifact/patchprocess/newPatchFindbugsWarningsstorm-bridge.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/190//artifact/patchprocess/newPatchFindbugsWarningsrepository.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/190//artifact/patchprocess/newPatchFindbugsWarningstypesystem.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/190//artifact/patchprocess/newPatchFindbugsWarningstitan.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/190//artifact/patchprocess/newPatchFindbugsWarningswebapp.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/190//artifact/patchprocess/newPatchFindbugsWarningsnotification.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/190//artifact/patchprocess/newPatchFindbugsWarningsclient.html
Console output: https://builds.apache.org/job/PreCommit-ATLAS-Build/190//console

This message is automatically generated.

> FieldMapping.output() results in stack overflow when instances reference each 
> other
> ---
>
> Key: ATLAS-645
> URL: https://issues.apache.org/jira/browse/ATLAS-645
> Project: Atlas
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: David Kantor
> Attachments: rb45948.patch
>
>
> FieldMapping.output() results in a stack overflow due to infinite recursion 
> when two IReferenceableInstance or IStruct objects reference each other.  
> This issue was first exposed by 
> GraphBackedMetadataRepositoryDeleteEntitiesTest.testDisconnectMapReferenceFromClassType().
> {noformat}
> SLF4J: Failed toString() invocation on an object of type 
> [org.apache.atlas.typesystem.persistence.ReferenceableInstance]
> java.lang.StackOverflowError
>   at java.util.regex.Pattern$GroupHead.match(Pattern.java:4556)
>   at java.util.regex.Pattern$Branch.match(Pattern.java:4502)
>   at java.util.regex.Pattern$BranchConn.match(Pattern.java:4466)
>   at java.util.regex.Pattern$GroupTail.match(Pattern.java:4615)
>   at java.util.regex.Pattern$Curly.match0(Pattern.java:4177)
>   at java.util.regex.Pattern$Curly.match(Pattern.java:4132)
>   at java.util.regex.Pattern$GroupHead.match(Pattern.java:4556)
>   at java.util.regex.Pattern$Branch.match(Pattern.java:4502)
>   at java.util.regex.Pattern$Branch.match(Pattern.java:4500)
>   at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3715)
>   at java.util.regex.Pattern$Start.match(Pattern.java:3408)
>   at java.util.regex.Matcher.search(Matcher.java:1199)
>   at java.util.regex.Matcher.find(Matcher.java:618)
>   at java.util.Formatter.parse(Formatter.java:2517)
>   at java.util.Formatter.format(Formatter.java:2469)
>   at java.util.Formatter.format(Formatter.java:2423)
>   at

[jira] [Updated] (ATLAS-645) FieldMapping.output() results in stack overflow when instances reference each other

2016-04-29 Thread David Kantor (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ATLAS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Kantor updated ATLAS-645:
---
Attachment: (was: rb45948.patch)

> FieldMapping.output() results in stack overflow when instances reference each 
> other
> ---
>
> Key: ATLAS-645
> URL: https://issues.apache.org/jira/browse/ATLAS-645
> Project: Atlas
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: David Kantor
> Attachments: rb45948.patch
>
>
> FieldMapping.output() results in a stack overflow due to infinite recursion 
> when two IReferenceableInstance or IStruct objects reference each other.  
> This issue was first exposed by 
> GraphBackedMetadataRepositoryDeleteEntitiesTest.testDisconnectMapReferenceFromClassType().
> {noformat}
> SLF4J: Failed toString() invocation on an object of type 
> [org.apache.atlas.typesystem.persistence.ReferenceableInstance]
> java.lang.StackOverflowError
>   at java.util.regex.Pattern$GroupHead.match(Pattern.java:4556)
>   at java.util.regex.Pattern$Branch.match(Pattern.java:4502)
>   at java.util.regex.Pattern$BranchConn.match(Pattern.java:4466)
>   at java.util.regex.Pattern$GroupTail.match(Pattern.java:4615)
>   at java.util.regex.Pattern$Curly.match0(Pattern.java:4177)
>   at java.util.regex.Pattern$Curly.match(Pattern.java:4132)
>   at java.util.regex.Pattern$GroupHead.match(Pattern.java:4556)
>   at java.util.regex.Pattern$Branch.match(Pattern.java:4502)
>   at java.util.regex.Pattern$Branch.match(Pattern.java:4500)
>   at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3715)
>   at java.util.regex.Pattern$Start.match(Pattern.java:3408)
>   at java.util.regex.Matcher.search(Matcher.java:1199)
>   at java.util.regex.Matcher.find(Matcher.java:618)
>   at java.util.Formatter.parse(Formatter.java:2517)
>   at java.util.Formatter.format(Formatter.java:2469)
>   at java.util.Formatter.format(Formatter.java:2423)
>   at java.lang.String.format(String.java:2792)
>   at org.apache.atlas.typesystem.persistence.Id.toString(Id.java:98)
>   at 
> org.apache.atlas.typesystem.types.FieldMapping.output(FieldMapping.java:114)
>   at 
> org.apache.atlas.typesystem.persistence.ReferenceableInstance.toString(ReferenceableInstance.java:92)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ATLAS-645) FieldMapping.output() results in stack overflow when instances reference each other

2016-04-29 Thread David Kantor (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ATLAS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Kantor updated ATLAS-645:
---
Attachment: rb45948.patch

Updated patch from review board

> FieldMapping.output() results in stack overflow when instances reference each 
> other
> ---
>
> Key: ATLAS-645
> URL: https://issues.apache.org/jira/browse/ATLAS-645
> Project: Atlas
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: David Kantor
> Attachments: rb45948.patch
>
>
> FieldMapping.output() results in a stack overflow due to infinite recursion 
> when two IReferenceableInstance or IStruct objects reference each other.  
> This issue was first exposed by 
> GraphBackedMetadataRepositoryDeleteEntitiesTest.testDisconnectMapReferenceFromClassType().
> {noformat}
> SLF4J: Failed toString() invocation on an object of type 
> [org.apache.atlas.typesystem.persistence.ReferenceableInstance]
> java.lang.StackOverflowError
>   at java.util.regex.Pattern$GroupHead.match(Pattern.java:4556)
>   at java.util.regex.Pattern$Branch.match(Pattern.java:4502)
>   at java.util.regex.Pattern$BranchConn.match(Pattern.java:4466)
>   at java.util.regex.Pattern$GroupTail.match(Pattern.java:4615)
>   at java.util.regex.Pattern$Curly.match0(Pattern.java:4177)
>   at java.util.regex.Pattern$Curly.match(Pattern.java:4132)
>   at java.util.regex.Pattern$GroupHead.match(Pattern.java:4556)
>   at java.util.regex.Pattern$Branch.match(Pattern.java:4502)
>   at java.util.regex.Pattern$Branch.match(Pattern.java:4500)
>   at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3715)
>   at java.util.regex.Pattern$Start.match(Pattern.java:3408)
>   at java.util.regex.Matcher.search(Matcher.java:1199)
>   at java.util.regex.Matcher.find(Matcher.java:618)
>   at java.util.Formatter.parse(Formatter.java:2517)
>   at java.util.Formatter.format(Formatter.java:2469)
>   at java.util.Formatter.format(Formatter.java:2423)
>   at java.lang.String.format(String.java:2792)
>   at org.apache.atlas.typesystem.persistence.Id.toString(Id.java:98)
>   at 
> org.apache.atlas.typesystem.types.FieldMapping.output(FieldMapping.java:114)
>   at 
> org.apache.atlas.typesystem.persistence.ReferenceableInstance.toString(ReferenceableInstance.java:92)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ATLAS-723) JSON deserialization regression

2016-04-29 Thread ATLAS QA (JIRA) 

[ 
https://issues.apache.org/jira/browse/ATLAS-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15264738#comment-15264738
 ] 

ATLAS QA commented on ATLAS-723:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment
  http://issues.apache.org/jira/secure/attachment/12801508/rb46849.patch
  against master revision 7d040c5.

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 1 new 
or modified test files.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javadoc{color}.  There were no new javadoc warning messages.

+1 checkstyle.  The patch generated 0 code style errors.

{color:red}-1 findbugs{color}.  The patch appears to introduce 361 new 
Findbugs (version 2.0.3) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:red}-1 core tests{color}.  The patch failed these unit tests in :
 
./webapp/test-output/junitreports/TEST-org.apache.atlas.web.resources.RexsterGraphJerseyResourceIT
./webapp/test-output/junitreports/TEST-org.apache.atlas.web.resources.AdminJerseyResourceIT
./webapp/test-output/junitreports/TEST-org.apache.atlas.web.resources.EntityJerseyResourceIT
./webapp/test-output/junitreports/TEST-org.apache.atlas.web.resources.MetadataDiscoveryJerseyResourceIT
./webapp/test-output/junitreports/TEST-org.apache.atlas.web.resources.TypesJerseyResourceIT

Test results: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/189//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/189//artifact/patchprocess/newPatchFindbugsWarningswebapp.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/189//artifact/patchprocess/newPatchFindbugsWarningscommon.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/189//artifact/patchprocess/newPatchFindbugsWarningssqoop-bridge.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/189//artifact/patchprocess/newPatchFindbugsWarningshdfs-model.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/189//artifact/patchprocess/newPatchFindbugsWarningsstorm-bridge.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/189//artifact/patchprocess/newPatchFindbugsWarningshive-bridge.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/189//artifact/patchprocess/newPatchFindbugsWarningsrepository.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/189//artifact/patchprocess/newPatchFindbugsWarningstypesystem.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/189//artifact/patchprocess/newPatchFindbugsWarningsclient.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/189//artifact/patchprocess/newPatchFindbugsWarningsnotification.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/189//artifact/patchprocess/newPatchFindbugsWarningstitan.html
Console output: https://builds.apache.org/job/PreCommit-ATLAS-Build/189//console

This message is automatically generated.

> JSON deserialization regression
> ---
>
> Key: ATLAS-723
> URL: https://issues.apache.org/jira/browse/ATLAS-723
> Project: Atlas
>  Issue Type: Bug
>Affects Versions: trunk
>Reporter: Jeffrey Hagelberg
>Assignee: Neeru Gupta
>Priority: Blocker
> Attachments: InstanceSerializationTest.scala, rb46849.patch
>
>
> Some json that could be deserialized prior to the implementation of soft 
> delete can no longer be deserialized.  This seems to be related to the 
> addition of the "state" field in the id.  Furthermore, it seems to be 
> restricted to cases where the object has an array reference.
> Here's an example of a JSON object whose deserialization now fails:
> {noformat}
>  {
> "jsonClass": 
> "org.apache.atlas.typesystem.json.InstanceSerialization$_Reference",
> "id": {
> "jsonClass": 
> "org.apache.atlas.typesystem.json.InstanceSerialization$_Id",
> "id": "6765f7c6-cc11-4575-8c13-8bab9b3d86a2",
> "version": 0,
> "typeName": "LoadProcess"
> },
> "typeName": "LoadProcess",
> "values": {
> "inputTables": [{
> "jsonClass": 
> "org.apache.atlas.typesystem.json.InstanceSerialization$_Id",
> "id": "bacfa996-e88e-4d7e-9630-68c9829b10b4",
> "version": 0,
> "typeName": "Table"
> }, {
> "jsonClass": 
>

[jira] [Updated] (ATLAS-723) JSON deserialization regression

2016-04-29 Thread Neeru Gupta (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ATLAS-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Neeru Gupta updated ATLAS-723:
--
Attachment: rb46849.patch

Attaching patch from review board https://reviews.apache.org/r/46849/

> JSON deserialization regression
> ---
>
> Key: ATLAS-723
> URL: https://issues.apache.org/jira/browse/ATLAS-723
> Project: Atlas
>  Issue Type: Bug
>Affects Versions: trunk
>Reporter: Jeffrey Hagelberg
>Assignee: Neeru Gupta
>Priority: Blocker
> Attachments: InstanceSerializationTest.scala, rb46849.patch
>
>
> Some json that could be deserialized prior to the implementation of soft 
> delete can no longer be deserialized.  This seems to be related to the 
> addition of the "state" field in the id.  Furthermore, it seems to be 
> restricted to cases where the object has an array reference.
> Here's an example of a JSON object whose deserialization now fails:
> {noformat}
>  {
> "jsonClass": 
> "org.apache.atlas.typesystem.json.InstanceSerialization$_Reference",
> "id": {
> "jsonClass": 
> "org.apache.atlas.typesystem.json.InstanceSerialization$_Id",
> "id": "6765f7c6-cc11-4575-8c13-8bab9b3d86a2",
> "version": 0,
> "typeName": "LoadProcess"
> },
> "typeName": "LoadProcess",
> "values": {
> "inputTables": [{
> "jsonClass": 
> "org.apache.atlas.typesystem.json.InstanceSerialization$_Id",
> "id": "bacfa996-e88e-4d7e-9630-68c9829b10b4",
> "version": 0,
> "typeName": "Table"
> }, {
> "jsonClass": 
> "org.apache.atlas.typesystem.json.InstanceSerialization$_Id",
> "id": "6da06805-3f56-446f-8831-672a65ac2199",
> "version": 0,
> "typeName": "Table"
> }
> ],
> "outputTable": {
> "jsonClass": 
> "org.apache.atlas.typesystem.json.InstanceSerialization$_Id",
> "id": "d5c3d6d0-aa10-44c1-b05d-ed9400d2a5ac",
> "version": 0,
> "typeName": "Table"
> },
> "name": "loadSalesDaily"
> },
> "traitNames": [
> "ETL"
> ],
> "traits": {
> "ETL": {
> "jsonClass": 
> "org.apache.atlas.typesystem.json.InstanceSerialization$_Struct",
> "typeName": "ETL",
> "values": {
> }
> }
> }
> }
> {noformat}
> (Note that this depends on the referenced Table objects having been 
> previously saved into Atlas)
> I spent some time debugging this today, it seems to be a regression in the 
> InstanceSerialization class.  It seems to be related to 
> InstanceJavaConversion.state and InstanceJavaConversion.convertId



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 45948: Atlas-645: avoid infinite recursion in FieldMapping.output()

2016-04-29 Thread David Kantor 


> On April 19, 2016, 11 a.m., Shwetha GS wrote:
> > typesystem/src/main/java/org/apache/atlas/typesystem/types/FieldMapping.java,
> >  line 99
> > 
> >
> > Can we maintain this as Set and check on just typeName?
> 
> David Kantor wrote:
> I don't understand how checking typeName would avoid the infinite 
> recursion.  The problem use case is when structs reference each other.  So 
> let's say there is a bi-directional reference between A and B.  When A is 
> output, its attribute values are output.  So then B is output, and when its 
> attributes are output, FieldMapping.output() is called recursively on A.  We 
> need to detect that A is already in the process of being output to avoid the 
> infinite recursion.  How does checking typeName help with this?  Please 
> advise.
> 
> Shwetha GS wrote:
> In FieldMappingTest.testOutputReferenceableInstance(), even 
> ownerType.toString() throws stack overflow. So, thought you were addressing 
> type.tostring()
> 
> For type.toString(), we can use typename. For instance.tostring(), can we 
> use id string, instead of full instance in the set

Thanks for pointing out the stack overflow on ownerType.toString().  This 
involves type system objects and does not go through the FieldMapping.output() 
and IDataType.output() code path for outputting instance data - it takes a 
completely different code path. So changing the "in process" arg on these 
methods to Set would not address this bug.  Here is the relevant call 
stack:
  
  ClassType(HierarchicalType).toString() line: 371
  String.valueOf(Object) line: 1657 
  StringBuilder.append(Object) line: 194
  AttributeInfo.toString() line: 65 
  SingletonImmutableList.toString() line: 97 
  String.valueOf(Object) line: 1657 
  StringBuilder.append(Object) line: 194
  ClassType(HierarchicalType).toString() line: 372
  String.valueOf(Object) line: 1657 
  StringBuilder.append(Object) line: 194
  AttributeInfo.toString() line: 65 
  SingletonImmutableList.toString() line: 97 
  String.valueOf(Object) line: 1657 
  StringBuilder.append(Object) line: 194
  ClassType(HierarchicalType).toString() line: 372

Also, for instance data, using the id string is not sufficient because structs 
that are not implementations of IReferenceableInstance won't have an id string. 
 And for those structs that are IReferenceableInstance objects, if the structs 
are newly created in memory and have not been persisted, they won't have a 
meaningful id string.  Such objects would all have the same id string, and 
result in false positives on the inProcess check.

I have re-implemented the fix to maintain the inProcess set in thread local 
storage rather than passing it as an argument.  This fix addresses the 
recursion issue for both types and instance data.


- David


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/45948/#review129505
---


On April 29, 2016, 7:24 p.m., David Kantor wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/45948/
> ---
> 
> (Updated April 29, 2016, 7:24 p.m.)
> 
> 
> Review request for atlas.
> 
> 
> Bugs: ATLAS-645
> https://issues.apache.org/jira/browse/ATLAS-645
> 
> 
> Repository: atlas
> 
> 
> Description
> ---
> 
> ATLAS-645: In FieldMapping.output(), avoid infinite recursion when 
> IReferenceableInstance and IStruct instances reference each other.
> 
> 
> Diffs
> -
> 
>   
> typesystem/src/main/java/org/apache/atlas/typesystem/persistence/StructInstance.java
>  af62442bfe5daa221079207acf361e1316cab3ad 
>   
> typesystem/src/main/java/org/apache/atlas/typesystem/types/FieldMapping.java 
> 36149bafff80b68ce176e82dcacac87035459362 
>   
> typesystem/src/main/java/org/apache/atlas/typesystem/types/HierarchicalType.java
>  89fcea6828c9e23c28a60952c3e4ca27c0667494 
>   
> typesystem/src/main/java/org/apache/atlas/typesystem/types/OutputStatus.java 
> PRE-CREATION 
>   typesystem/src/main/java/org/apache/atlas/typesystem/types/StructType.java 
> 54e344f5d6322a00ac7825ee8964f43a1552dcbe 
>   
> typesystem/src/test/java/org/apache/atlas/typesystem/types/OutputStatusTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/45948/diff/
> 
> 
> Testing
> ---
> 
> Ran all unit and integration tests with no regressions.  Added test cases
> 
> 
> Thanks,
> 
> David Kantor
> 
>

Re: Review Request 45948: Atlas-645: avoid infinite recursion in FieldMapping.output()

2016-04-29 Thread David Kantor 


> On April 22, 2016, 6:41 a.m., Shwetha GS wrote:
> > typesystem/src/main/java/org/apache/atlas/typesystem/persistence/StructInstance.java,
> >  line 728
> > 
> >
> > Why is this removed?

I removed it because it was not being called anywhere and duplicated 
code/functionality available elsewhere.  If there is usage of this method that 
I missed, please advise.


> On April 22, 2016, 6:41 a.m., Shwetha GS wrote:
> > typesystem/src/main/java/org/apache/atlas/typesystem/types/AbstractDataType.java,
> >  line 48
> > 
> >
> > rename to outputInProgress everywhere?

I've removed the inProcess method argument.


- David


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/45948/#review130045
---


On April 29, 2016, 7:24 p.m., David Kantor wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/45948/
> ---
> 
> (Updated April 29, 2016, 7:24 p.m.)
> 
> 
> Review request for atlas.
> 
> 
> Bugs: ATLAS-645
> https://issues.apache.org/jira/browse/ATLAS-645
> 
> 
> Repository: atlas
> 
> 
> Description
> ---
> 
> ATLAS-645: In FieldMapping.output(), avoid infinite recursion when 
> IReferenceableInstance and IStruct instances reference each other.
> 
> 
> Diffs
> -
> 
>   
> typesystem/src/main/java/org/apache/atlas/typesystem/persistence/StructInstance.java
>  af62442bfe5daa221079207acf361e1316cab3ad 
>   
> typesystem/src/main/java/org/apache/atlas/typesystem/types/FieldMapping.java 
> 36149bafff80b68ce176e82dcacac87035459362 
>   
> typesystem/src/main/java/org/apache/atlas/typesystem/types/HierarchicalType.java
>  89fcea6828c9e23c28a60952c3e4ca27c0667494 
>   
> typesystem/src/main/java/org/apache/atlas/typesystem/types/OutputStatus.java 
> PRE-CREATION 
>   typesystem/src/main/java/org/apache/atlas/typesystem/types/StructType.java 
> 54e344f5d6322a00ac7825ee8964f43a1552dcbe 
>   
> typesystem/src/test/java/org/apache/atlas/typesystem/types/OutputStatusTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/45948/diff/
> 
> 
> Testing
> ---
> 
> Ran all unit and integration tests with no regressions.  Added test cases
> 
> 
> Thanks,
> 
> David Kantor
> 
>

Re: Review Request 45948: Atlas-645: avoid infinite recursion in FieldMapping.output()

2016-04-29 Thread David Kantor 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/45948/
---

(Updated April 29, 2016, 7:24 p.m.)


Review request for atlas.


Changes
---

Addressed Shwetha's comments.  Reimplemented to use thread local storage for 
the inProcess set rather than passing as an method argument.


Bugs: ATLAS-645
https://issues.apache.org/jira/browse/ATLAS-645


Repository: atlas


Description
---

ATLAS-645: In FieldMapping.output(), avoid infinite recursion when 
IReferenceableInstance and IStruct instances reference each other.


Diffs (updated)
-

  
typesystem/src/main/java/org/apache/atlas/typesystem/persistence/StructInstance.java
 af62442bfe5daa221079207acf361e1316cab3ad 
  typesystem/src/main/java/org/apache/atlas/typesystem/types/FieldMapping.java 
36149bafff80b68ce176e82dcacac87035459362 
  
typesystem/src/main/java/org/apache/atlas/typesystem/types/HierarchicalType.java
 89fcea6828c9e23c28a60952c3e4ca27c0667494 
  typesystem/src/main/java/org/apache/atlas/typesystem/types/OutputStatus.java 
PRE-CREATION 
  typesystem/src/main/java/org/apache/atlas/typesystem/types/StructType.java 
54e344f5d6322a00ac7825ee8964f43a1552dcbe 
  
typesystem/src/test/java/org/apache/atlas/typesystem/types/OutputStatusTest.java
 PRE-CREATION 

Diff: https://reviews.apache.org/r/45948/diff/


Testing
---

Ran all unit and integration tests with no regressions.  Added test cases


Thanks,

David Kantor

[jira] [Assigned] (ATLAS-619) Partition queries should be normalized when tracking lineage at table

2016-04-29 Thread Suma Shivaprasad (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ATLAS-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suma Shivaprasad reassigned ATLAS-619:
--

Assignee: Suma Shivaprasad

> Partition queries should be normalized when  tracking lineage at table
> --
>
> Key: ATLAS-619
> URL: https://issues.apache.org/jira/browse/ATLAS-619
> Project: Atlas
>  Issue Type: Bug
>Affects Versions: 0.7-incubating
>Reporter: Suma Shivaprasad
>Assignee: Suma Shivaprasad
>
> Partition type and entities are no loner being created after ATLAS-599. Even 
> prior to this change , the linage for partition based queries are being 
> tracked at the table level and not at the partition level which would be 
> ideal. To track at the table level, the queries should be canonicialized for 
> the partition values or only the latest few partition queries should be 
> tracked since otherwise there could be potentially thousands of such queries 
> while tracking lineage.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ATLAS-497) Simple Authorization

2016-04-29 Thread Saqeeb Shaikh (JIRA) 

[ 
https://issues.apache.org/jira/browse/ATLAS-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15264200#comment-15264200
 ] 

Saqeeb Shaikh commented on ATLAS-497:
-

Thanks [~yhemanth] for reviewing the patch. Please find my comments inline.


* Do we have a requirement for separating creates and updates? Can we merge 
them into one write operation? In fact many operations in Atlas backend are a 
create or update kind of operation. Merging into one may be better, IMHO.
** *Can we please finalize the requirement for this and track it as part of 
another JIRA?*
* In AtlasAccessRequest and PolicyUtil there are many unused methods. Please 
remove them.
** *Some of the unused methods from AtlasAccessRequest, will be used when I add 
support for RangerPlugin. I will remove the setter methods from the 
PolicyUtils.*

* In the authorization code path where AtlasException is thrown due to 
authorization problems, maybe it is better to throw a custom 
AtlasAuthorizationException. This could have information about what was 
attempted to be accessed etc.
** *Will make this change*

* For requests that require access to multiple resource types (e.g. paths like 
entities/traits - which requires access to both entities & traits), access 
should be granted only if all of them are allowed, no? Currently, even if one 
matches we are allowing access, as far as I can tell.
** *Yes, you are right, the access to such resources is granted only if the 
user or group have access to both the resource types. In 
SimpleAtlasAuthorizer.checkAccess() method, I am iterating through each of the 
resourceTypes that the user has access to and if he has access to all of them 
only then he is granted access.*

* Currently, since we don't have resource specific match, in 
SimpleAtlasAuthorizer, can we simplify the resource check logic and just check 
for access to resourcetypes for now?
** *Yes, I can change it for now, however I had added this keeping in mind that 
down the line we will support resource filtering as well.*

* Without the above, there are some important issues: for e.g. since 
SimpleAtlasAuthorizer is a singleton object, the value isMatchAny is being 
accessed in a non-thread safe manner.
** *Yes, I will fix this*

* In a later JIRA, we'll need to figure how principal information like user 
name / groups will be got in Kerberos authentication case. This is because 
currently we are picking these up from Spring security context.
** *Yes,  I will raise another JIRA for this.*

* Can we please add a merge test in PolicyUtilTest - one that has > 1 policies 
with different (possibly conflicting) rules and see how the end result works 
out?
* Please add some tests for AtlasAuthorizationFilter.
**  *Yes, I am adding more test cases for this feature.*

> Simple Authorization
> 
>
> Key: ATLAS-497
> URL: https://issues.apache.org/jira/browse/ATLAS-497
> Project: Atlas
>  Issue Type: New Feature
>Affects Versions: 0.7-incubating
>Reporter: Erik Bergenholtz
>Assignee: Saqeeb Shaikh
> Fix For: 0.7-incubating
>
> Attachments: ATLAS-497.1.patch, ATLAS-497.2.patch, ATLAS-497.patch
>
>
> Atlas needs to support a simple (out of box) authorization mechanism.
> Defined Roles:
> - Data Scientist: provides a read only view (GET)
> - Data Steward: provides a read/edit view (PUT, POST, DELETE)
> - Admin (can do anything)
> All can comment on entity
> Requirements
> - Atlas will implement a simple file based store for providing user to role 
> mapping
> - The out of box experience will be this file based mechanism for 
> authorization



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 45720: Introduce Versioning to Atlas Notification Payload

2016-04-29 Thread Tom Beerbower 


> On April 25, 2016, 6:10 p.m., Shwetha GS wrote:
> > notification/src/main/java/org/apache/atlas/notification/VersionedMessageDeserializer.java,
> >  line 91
> > 
> >
> > Lets take the case of one of the notification consumers, ranger. They 
> > will not override log4j.configuration to point to atlas-log4j.xml. They 
> > will have their own log4j.xml. And we can't force them to define the custom 
> > log appenders for entity notification in their log4j.xml. So, these log 
> > messages will use the default log appender and they need to go through this 
> > code to figure out the appender that this log statement uses. Instead, lets 
> > use the default class logger, in which case their log appender 
> > configuration for 'org.apache.atlas' package will work for these log 
> > statemnets as well.
> > 
> > Its upto the consumers on how they want to handle incompatible 
> > versioned messages. Instead of logging to another file, we should use 
> > default logger(as explained above) and throw exception. Some consumers may 
> > want to fail even with 1 incompatible message, some may want to fail with n 
> > incompatible messages and others might log and ignore. Lets leave it upto 
> > the consumers
> > 
> > In NotificationHookConsumer, because we are the consumer for hook 
> > messages in this case, we can catch IncompatibleVersionException, and log 
> > to another file and continue.
> 
> Shwetha GS wrote:
> Did you have plans of writing failed messages from 
> NotificationHookConsumer to a file so that it can be re-processed. Can be 
> done in another jira as well. Just checking

Maybe best to handle in another Jira.  I don't think that it becomes an issue 
until we introduce a new version of the hook messages.  Thanks.


- Tom


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/45720/#review130472
---


On April 26, 2016, 2:26 p.m., Tom Beerbower wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/45720/
> ---
> 
> (Updated April 26, 2016, 2:26 p.m.)
> 
> 
> Review request for atlas.
> 
> 
> Bugs: ATLAS-631
> https://issues.apache.org/jira/browse/ATLAS-631
> 
> 
> Repository: atlas
> 
> 
> Description
> ---
> 
> 1. Introduce Versioning to Atlas Notification Payload (both ways)
> 2. For any messages that are not able to be processed, log the message do a 
> separate log file for unprocessed messages.
> 
> 
> Diffs
> -
> 
>   notification/src/main/java/org/apache/atlas/kafka/KafkaConsumer.java 
> 029a072 
>   notification/src/main/java/org/apache/atlas/kafka/KafkaNotification.java 
> 889af11 
>   
> notification/src/main/java/org/apache/atlas/notification/AbstractMessageDeserializer.java
>  PRE-CREATION 
>   
> notification/src/main/java/org/apache/atlas/notification/AbstractNotification.java
>  596f988 
>   
> notification/src/main/java/org/apache/atlas/notification/AbstractNotificationConsumer.java
>  1cadb99 
>   
> notification/src/main/java/org/apache/atlas/notification/IncompatibleVersionException.java
>  PRE-CREATION 
>   
> notification/src/main/java/org/apache/atlas/notification/MessageDeserializer.java
>  PRE-CREATION 
>   
> notification/src/main/java/org/apache/atlas/notification/MessageVersion.java 
> PRE-CREATION 
>   
> notification/src/main/java/org/apache/atlas/notification/NotificationInterface.java
>  ac285aa 
>   
> notification/src/main/java/org/apache/atlas/notification/VersionedMessage.java
>  PRE-CREATION 
>   
> notification/src/main/java/org/apache/atlas/notification/VersionedMessageDeserializer.java
>  PRE-CREATION 
>   
> notification/src/main/java/org/apache/atlas/notification/entity/EntityMessageDeserializer.java
>  PRE-CREATION 
>   
> notification/src/main/java/org/apache/atlas/notification/hook/HookMessageDeserializer.java
>  PRE-CREATION 
>   notification/src/test/java/org/apache/atlas/kafka/KafkaConsumerTest.java 
> PRE-CREATION 
>   
> notification/src/test/java/org/apache/atlas/kafka/KafkaNotificationTest.java 
> db34815 
>   
> notification/src/test/java/org/apache/atlas/notification/AbstractNotificationConsumerTest.java
>  PRE-CREATION 
>   
> notification/src/test/java/org/apache/atlas/notification/AbstractNotificationTest.java
>  PRE-CREATION 
>   
> notification/src/test/java/org/apache/atlas/notification/MessageVersionTest.java
>  PRE-CREATION 
>   
> notification/src/test/java/org/apache/atlas/notification/VersionedMessageTest.java
>  PRE-CREATION 
>   
> notification/src/test/java/org/apache/atlas/notification/entity/EntityMessageDeserializerTest.java
>  PRE-CREATION 
>   
>

[jira] [Commented] (ATLAS-672) UI: Make dashboard v2 the default UI implementation

2016-04-29 Thread Erik Bergenholtz (JIRA) 

[ 
https://issues.apache.org/jira/browse/ATLAS-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15264039#comment-15264039
 ] 

Erik Bergenholtz commented on ATLAS-672:


[~yhemanth] - verified ATLAS-672-1.patch, local build, deploy + testing using 
quick start.

Thanks for fixing RAT check issue, sorry I missed this.

+1 LGTM.

> UI: Make dashboard v2 the default UI implementation
> ---
>
> Key: ATLAS-672
> URL: https://issues.apache.org/jira/browse/ATLAS-672
> Project: Atlas
>  Issue Type: Task
>Affects Versions: 0.7-incubating
>Reporter: Erik Bergenholtz
>Assignee: Erik Bergenholtz
> Fix For: 0.7-incubating
>
> Attachments: ATLAS-672-1.patch, ATLAS-672.patch
>
>
> Now that dasboardv2 has been a part of the code base for some time, I propose 
> that we move to using this implementation in favor of the older dashboard 
> implementation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ATLAS-728) Fix few typos in committer email IDs

2016-04-29 Thread ATLAS QA (JIRA) 

[ 
https://issues.apache.org/jira/browse/ATLAS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263967#comment-15263967
 ] 

ATLAS QA commented on ATLAS-728:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment
  http://issues.apache.org/jira/secure/attachment/12801437/ATLAS-728.patch
  against master revision 7d040c5.

{color:red}-1 patch{color}.  The patch command could not apply the patch.

Console output: https://builds.apache.org/job/PreCommit-ATLAS-Build/188//console

This message is automatically generated.

> Fix few typos in committer email IDs
> 
>
> Key: ATLAS-728
> URL: https://issues.apache.org/jira/browse/ATLAS-728
> Project: Atlas
>  Issue Type: Bug
>Reporter: Hemanth Yamijala
>Assignee: Hemanth Yamijala
> Attachments: ATLAS-728.patch
>
>
> pom.xml has some typos in committer email IDs. Filing this ticket to fix them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ATLAS-672) UI: Make dashboard v2 the default UI implementation

2016-04-29 Thread ATLAS QA (JIRA) 

[ 
https://issues.apache.org/jira/browse/ATLAS-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263966#comment-15263966
 ] 

ATLAS QA commented on ATLAS-672:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment
  http://issues.apache.org/jira/secure/attachment/12801435/ATLAS-672-1.patch
  against master revision 574da75.

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:red}-1 tests included{color}.  The patch doesn't appear to include 
any new or modified tests.
Please justify why no new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javadoc{color}.  There were no new javadoc warning messages.

+1 checkstyle.  The patch generated 0 code style errors.

{color:red}-1 findbugs{color}.  The patch appears to introduce 361 new 
Findbugs (version 2.0.3) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:red}-1 core tests{color}.  The patch failed these unit tests in :
 
./repository/target/surefire-reports/junitreports/TEST-org.apache.atlas.service.DefaultMetadataServiceTest
./repository/target/surefire-reports/junitreports/TEST-org.apache.atlas.repository.audit.HBaseBasedAuditRepositoryTest
  org.apache.atlas.service.DefaultMetadataServiceTest
  
org.apache.atlas.repository.audit.HBaseBasedAuditRepositoryTest

Test results: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/187//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/187//artifact/patchprocess/newPatchFindbugsWarningswebapp.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/187//artifact/patchprocess/newPatchFindbugsWarningsnotification.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/187//artifact/patchprocess/newPatchFindbugsWarningshdfs-model.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/187//artifact/patchprocess/newPatchFindbugsWarningshive-bridge.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/187//artifact/patchprocess/newPatchFindbugsWarningsstorm-bridge.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/187//artifact/patchprocess/newPatchFindbugsWarningssqoop-bridge.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/187//artifact/patchprocess/newPatchFindbugsWarningsclient.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/187//artifact/patchprocess/newPatchFindbugsWarningscommon.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/187//artifact/patchprocess/newPatchFindbugsWarningstypesystem.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/187//artifact/patchprocess/newPatchFindbugsWarningsrepository.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ATLAS-Build/187//artifact/patchprocess/newPatchFindbugsWarningstitan.html
Console output: https://builds.apache.org/job/PreCommit-ATLAS-Build/187//console

This message is automatically generated.

> UI: Make dashboard v2 the default UI implementation
> ---
>
> Key: ATLAS-672
> URL: https://issues.apache.org/jira/browse/ATLAS-672
> Project: Atlas
>  Issue Type: Task
>Affects Versions: 0.7-incubating
>Reporter: Erik Bergenholtz
>Assignee: Erik Bergenholtz
> Fix For: 0.7-incubating
>
> Attachments: ATLAS-672-1.patch, ATLAS-672.patch
>
>
> Now that dasboardv2 has been a part of the code base for some time, I propose 
> that we move to using this implementation in favor of the older dashboard 
> implementation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ATLAS-469) Create a new release version for the next release

2016-04-29 Thread Selvamohan Neethiraj (JIRA) 

[ 
https://issues.apache.org/jira/browse/ATLAS-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263963#comment-15263963
 ] 

Selvamohan Neethiraj commented on ATLAS-469:


[~shwethags] - Since you have created '0.7-incubating', can you please mark 
this as CLOSED ?

> Create a new release version for the next release
> -
>
> Key: ATLAS-469
> URL: https://issues.apache.org/jira/browse/ATLAS-469
> Project: Atlas
>  Issue Type: Task
>Reporter: Selvamohan Neethiraj
>Priority: Critical
>
> Currently, all changes are being tracked as version - 'trunk' ... Instead, I 
> suggest that we create the next possible release '0.7.0-incubating' and 
> create a roadmap for all features and bugfixes for the specific release 
> version.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ATLAS-728) Fix few typos in committer email IDs

2016-04-29 Thread Shwetha G S (JIRA) 

[ 
https://issues.apache.org/jira/browse/ATLAS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263889#comment-15263889
 ] 

Shwetha G S commented on ATLAS-728:
---

+1

> Fix few typos in committer email IDs
> 
>
> Key: ATLAS-728
> URL: https://issues.apache.org/jira/browse/ATLAS-728
> Project: Atlas
>  Issue Type: Bug
>Reporter: Hemanth Yamijala
>Assignee: Hemanth Yamijala
> Attachments: ATLAS-728.patch
>
>
> pom.xml has some typos in committer email IDs. Filing this ticket to fix them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ATLAS-728) Fix few typos in committer email IDs

2016-04-29 Thread Hemanth Yamijala (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ATLAS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hemanth Yamijala updated ATLAS-728:
---
Attachment: ATLAS-728.patch

Trivial patch for review.

> Fix few typos in committer email IDs
> 
>
> Key: ATLAS-728
> URL: https://issues.apache.org/jira/browse/ATLAS-728
> Project: Atlas
>  Issue Type: Bug
>Reporter: Hemanth Yamijala
>Assignee: Hemanth Yamijala
> Attachments: ATLAS-728.patch
>
>
> pom.xml has some typos in committer email IDs. Filing this ticket to fix them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ATLAS-728) Fix few typos in committer email IDs

2016-04-29 Thread Hemanth Yamijala (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ATLAS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hemanth Yamijala updated ATLAS-728:
---
Description: pom.xml has some typos in committer email IDs. Filing this 
ticket to fix them.  (was: pom.xml has some typos in contributor email IDs. 
Filing this ticket to fix them.)

> Fix few typos in committer email IDs
> 
>
> Key: ATLAS-728
> URL: https://issues.apache.org/jira/browse/ATLAS-728
> Project: Atlas
>  Issue Type: Bug
>Reporter: Hemanth Yamijala
>
> pom.xml has some typos in committer email IDs. Filing this ticket to fix them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (ATLAS-728) Fix few typos in committer email IDs

2016-04-29 Thread Hemanth Yamijala (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ATLAS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hemanth Yamijala reassigned ATLAS-728:
--

Assignee: Hemanth Yamijala

> Fix few typos in committer email IDs
> 
>
> Key: ATLAS-728
> URL: https://issues.apache.org/jira/browse/ATLAS-728
> Project: Atlas
>  Issue Type: Bug
>Reporter: Hemanth Yamijala
>Assignee: Hemanth Yamijala
>
> pom.xml has some typos in committer email IDs. Filing this ticket to fix them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ATLAS-728) Fix few typos in committer email IDs

2016-04-29 Thread Hemanth Yamijala (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ATLAS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hemanth Yamijala updated ATLAS-728:
---
Summary: Fix few typos in committer email IDs  (was: Fix few typos in 
contributor email IDs)

> Fix few typos in committer email IDs
> 
>
> Key: ATLAS-728
> URL: https://issues.apache.org/jira/browse/ATLAS-728
> Project: Atlas
>  Issue Type: Bug
>Reporter: Hemanth Yamijala
>
> pom.xml has some typos in contributor email IDs. Filing this ticket to fix 
> them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ATLAS-728) Fix few typos in contributor email IDs

2016-04-29 Thread Hemanth Yamijala (JIRA) 
Hemanth Yamijala created ATLAS-728:
--

 Summary: Fix few typos in contributor email IDs
 Key: ATLAS-728
 URL: https://issues.apache.org/jira/browse/ATLAS-728
 Project: Atlas
  Issue Type: Bug
Reporter: Hemanth Yamijala


pom.xml has some typos in contributor email IDs. Filing this ticket to fix them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ATLAS-672) UI: Make dashboard v2 the default UI implementation

2016-04-29 Thread JIRA 

[ 
https://issues.apache.org/jira/browse/ATLAS-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263878#comment-15263878
 ] 

Jean-Baptiste Onofré commented on ATLAS-672:


Sure: let me summarize what I saw.

> UI: Make dashboard v2 the default UI implementation
> ---
>
> Key: ATLAS-672
> URL: https://issues.apache.org/jira/browse/ATLAS-672
> Project: Atlas
>  Issue Type: Task
>Affects Versions: 0.7-incubating
>Reporter: Erik Bergenholtz
>Assignee: Erik Bergenholtz
> Fix For: 0.7-incubating
>
> Attachments: ATLAS-672-1.patch, ATLAS-672.patch
>
>
> Now that dasboardv2 has been a part of the code base for some time, I propose 
> that we move to using this implementation in favor of the older dashboard 
> implementation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ATLAS-672) UI: Make dashboard v2 the default UI implementation

2016-04-29 Thread Hemanth Yamijala (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ATLAS-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hemanth Yamijala updated ATLAS-672:
---
Attachment: ATLAS-672-1.patch

[~bergenholtz], in general +1 for the patch. I just made a few changes in this 
new patch (ATLAS-672-1.patch):

* Left the dashboard (v1) module settings in the pom under comments. That way, 
if someone wants to switch during transition period, they can do so easily.
* There was one failure in RAT checkin when I ran the build. This I fixed by 
making the following entry to RAT exclude files:
{code}
-.bowerrc
+**/.bowerrc
{code}

I tested the patch by building and deploying it. The new UI shows up. Most of 
the existing functionality is intact (with some minor issues that can easily be 
addressed in subsequent JIRAs). Indeed, the new UI looks sleeker at least to me.

If you can review my changes, we could go ahead committing it.

[~j...@nanthrax.net], you mentioned you were testing the new dashboard. Can you 
please let us know if there're any issues you'd like to see fixed in this 
patch, as opposed to taking them as improvements / fixes later? Will wait for a 
day to hear back from you before commit.

> UI: Make dashboard v2 the default UI implementation
> ---
>
> Key: ATLAS-672
> URL: https://issues.apache.org/jira/browse/ATLAS-672
> Project: Atlas
>  Issue Type: Task
>Affects Versions: 0.7-incubating
>Reporter: Erik Bergenholtz
>Assignee: Erik Bergenholtz
> Fix For: 0.7-incubating
>
> Attachments: ATLAS-672-1.patch, ATLAS-672.patch
>
>
> Now that dasboardv2 has been a part of the code base for some time, I propose 
> that we move to using this implementation in favor of the older dashboard 
> implementation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ATLAS-556) Hive hook fails for select without table

2016-04-29 Thread Vimal Sharma (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ATLAS-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vimal Sharma resolved ATLAS-556.

Resolution: Resolved

Closing the ticket
Please reopen if other users report the same issue.

> Hive hook fails for select without table
> 
>
> Key: ATLAS-556
> URL: https://issues.apache.org/jira/browse/ATLAS-556
> Project: Atlas
>  Issue Type: Bug
>Reporter: Shwetha G S
>Assignee: Vimal Sharma
> Fix For: 0.7-incubating
>
>
> Reported from: From 
> https://community.hortonworks.com/questions/21766/hive-queries-without-from-clause-seem-to-fail-when.html
> Command: select 42
> {noformat}
> 2016-03-09 11:30:05,669 WARN  - [main:] ~ Failed to get database 
> _dummy_database, returning NoSuchObjectException (ObjectStore:568)
> FAILED: Hive Internal Error: java.lang.NullPointerException(null)
> java.lang.NullPointerException
> at 
> org.apache.atlas.hive.hook.HiveHook.createOrUpdateEntities(HiveHook.java:325)
> at 
> org.apache.atlas.hive.hook.HiveHook.registerProcess(HiveHook.java:387)
> at 
> org.apache.atlas.hive.hook.HiveHook.fireAndForget(HiveHook.java:224)
> at org.apache.atlas.hive.hook.HiveHook.run(HiveHook.java:182)
> at org.apache.hadoop.hive.ql.Driver.execute(Driver.java:1520)
> at org.apache.hadoop.hive.ql.Driver.runInternal(Driver.java:1195)
> at org.apache.hadoop.hive.ql.Driver.run(Driver.java:1059)
> at org.apache.hadoop.hive.ql.Driver.run(Driver.java:1049)
> at 
> org.apache.atlas.hive.hook.HiveHookIT.runCommand(HiveHookIT.java:75)
> at 
> org.apache.atlas.hive.hook.HiveHookIT.testSelect2(HiveHookIT.java:265)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:673)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:842)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1166)
> at 
> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:1178)
> at org.testng.TestRunner.privateRun(TestRunner.java:757)
> at org.testng.TestRunner.run(TestRunner.java:608)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
> at org.testng.SuiteRunner.run(SuiteRunner.java:240)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1158)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1083)
> at org.testng.TestNG.run(TestNG.java:999)
> at 
> org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:115)
> at 
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeSingleClass(TestNGDirectoryTestSuite.java:129)
> at 
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:113)
> at 
> org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:111)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ATLAS-497) Simple Authorization

2016-04-29 Thread Hemanth Yamijala (JIRA) 

[ 
https://issues.apache.org/jira/browse/ATLAS-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263662#comment-15263662
 ] 

Hemanth Yamijala commented on ATLAS-497:


Also, I have several other code improvement / simplification comments that I 
think will greatly improve the quality of this patch. However, to break work up 
into smaller units, maybe these can be done in a follow-up patch. I will create 
a separate JIRA for those (in case there are no objections from the community 
for this).

> Simple Authorization
> 
>
> Key: ATLAS-497
> URL: https://issues.apache.org/jira/browse/ATLAS-497
> Project: Atlas
>  Issue Type: New Feature
>Affects Versions: 0.7-incubating
>Reporter: Erik Bergenholtz
>Assignee: Saqeeb Shaikh
> Fix For: 0.7-incubating
>
> Attachments: ATLAS-497.1.patch, ATLAS-497.2.patch, ATLAS-497.patch
>
>
> Atlas needs to support a simple (out of box) authorization mechanism.
> Defined Roles:
> - Data Scientist: provides a read only view (GET)
> - Data Steward: provides a read/edit view (PUT, POST, DELETE)
> - Admin (can do anything)
> All can comment on entity
> Requirements
> - Atlas will implement a simple file based store for providing user to role 
> mapping
> - The out of box experience will be this file based mechanism for 
> authorization



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ATLAS-497) Simple Authorization

2016-04-29 Thread Hemanth Yamijala (JIRA) 

[ 
https://issues.apache.org/jira/browse/ATLAS-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263656#comment-15263656
 ] 

Hemanth Yamijala commented on ATLAS-497:


Few comments:

* Do we have a requirement for separating creates and updates? Can we merge 
them into one write operation? In fact many operations in Atlas backend are a 
create or update kind of operation. Merging into one may be better, IMHO.
* In AtlasAccessRequest and PolicyUtil there are many unused methods. Please 
remove them.
* In the authorization code path where AtlasException is thrown due to 
authorization problems, maybe it is better to throw a custom 
AtlasAuthorizationException. This could have information about what was 
attempted to be accessed etc.
* For requests that require access to multiple resource types (e.g. paths like 
entities/traits - which requires access to both entities & traits), access 
should be granted only if all of them are allowed, no? Currently, even if one 
matches we are allowing access, as far as I can tell.
* Currently, since we don't have resource specific match, in 
SimpleAtlasAuthorizer, can we simplify the resource check logic and just check 
for access to resourcetypes for now?
* Without the above, there are some important issues: for e.g. since 
SimpleAtlasAuthorizer is a singleton object, the value isMatchAny is being 
accessed in a non-thread safe manner.
* In a later JIRA, we'll need to figure how principal information like user 
name / groups will be got in Kerberos authentication case. This is because 
currently we are picking these up from Spring security context.
* Can we please add a merge test in PolicyUtilTest - one that has > 1 policies 
with different (possibly conflicting) rules and see how the end result works 
out?
* Please add some tests for AtlasAuthorizationFilter.

> Simple Authorization
> 
>
> Key: ATLAS-497
> URL: https://issues.apache.org/jira/browse/ATLAS-497
> Project: Atlas
>  Issue Type: New Feature
>Affects Versions: 0.7-incubating
>Reporter: Erik Bergenholtz
>Assignee: Saqeeb Shaikh
> Fix For: 0.7-incubating
>
> Attachments: ATLAS-497.1.patch, ATLAS-497.2.patch, ATLAS-497.patch
>
>
> Atlas needs to support a simple (out of box) authorization mechanism.
> Defined Roles:
> - Data Scientist: provides a read only view (GET)
> - Data Steward: provides a read/edit view (PUT, POST, DELETE)
> - Admin (can do anything)
> All can comment on entity
> Requirements
> - Atlas will implement a simple file based store for providing user to role 
> mapping
> - The out of box experience will be this file based mechanism for 
> authorization



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)