[jira] [Updated] (ATLAS-3611) update AtlasEntityDef with addition of read-only field namespaceAttributeDefs
[ https://issues.apache.org/jira/browse/ATLAS-3611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Madhan Neethiraj updated ATLAS-3611: Summary: update AtlasEntityDef with addition of read-only field namespaceAttributeDefs (was: updated AtlasEntityDef with addition of read-only field namespaceAttributeDefs) > update AtlasEntityDef with addition of read-only field namespaceAttributeDefs > - > > Key: ATLAS-3611 > URL: https://issues.apache.org/jira/browse/ATLAS-3611 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Reporter: Madhan Neethiraj >Assignee: Madhan Neethiraj >Priority: Major > Fix For: 2.1.0, 3.0.0 > > Attachments: ATLAS-3611.patch > > > An entity-type can be assigned a number of namespace-attributes, via > applicableEntityTypes option in namespace-attribute-def. Having entity-def > include namespace-attributes assigned to it can be helpful for applications > like UI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ATLAS-3611) updated AtlasEntityDef with addition of read-only field namespaceAttributeDefs
[ https://issues.apache.org/jira/browse/ATLAS-3611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17034173#comment-17034173 ] ASF subversion and git services commented on ATLAS-3611: Commit 437dc67fd973f65e92997a9f6c59796d0485a73c in atlas's branch refs/heads/branch-2.0 from Madhan Neethiraj [ https://gitbox.apache.org/repos/asf?p=atlas.git;h=437dc67 ] ATLAS-3611: updated AtlasEntityDef with addition of read-only field namespaceAttributeDefs (cherry picked from commit cc2e6af70586ade872181e51792577934a2141eb) > updated AtlasEntityDef with addition of read-only field namespaceAttributeDefs > -- > > Key: ATLAS-3611 > URL: https://issues.apache.org/jira/browse/ATLAS-3611 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Reporter: Madhan Neethiraj >Assignee: Madhan Neethiraj >Priority: Major > Fix For: 2.1.0, 3.0.0 > > Attachments: ATLAS-3611.patch > > > An entity-type can be assigned a number of namespace-attributes, via > applicableEntityTypes option in namespace-attribute-def. Having entity-def > include namespace-attributes assigned to it can be helpful for applications > like UI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ATLAS-3611) updated AtlasEntityDef with addition of read-only field namespaceAttributeDefs
[ https://issues.apache.org/jira/browse/ATLAS-3611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17034163#comment-17034163 ] ASF subversion and git services commented on ATLAS-3611: Commit cc2e6af70586ade872181e51792577934a2141eb in atlas's branch refs/heads/master from Madhan Neethiraj [ https://gitbox.apache.org/repos/asf?p=atlas.git;h=cc2e6af ] ATLAS-3611: updated AtlasEntityDef with addition of read-only field namespaceAttributeDefs > updated AtlasEntityDef with addition of read-only field namespaceAttributeDefs > -- > > Key: ATLAS-3611 > URL: https://issues.apache.org/jira/browse/ATLAS-3611 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Reporter: Madhan Neethiraj >Assignee: Madhan Neethiraj >Priority: Major > Fix For: 2.1.0, 3.0.0 > > Attachments: ATLAS-3611.patch > > > An entity-type can be assigned a number of namespace-attributes, via > applicableEntityTypes option in namespace-attribute-def. Having entity-def > include namespace-attributes assigned to it can be helpful for applications > like UI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Review Request 72102: ATLAS-3611: updated AtlasEntityDef with addition of read-only field namespaceAttributeDefs
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/72102/#review219537 --- Ship it! Ship It! - Nixon Rodrigues On Feb. 10, 2020, 1:33 a.m., Madhan Neethiraj wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/72102/ > --- > > (Updated Feb. 10, 2020, 1:33 a.m.) > > > Review request for atlas, Ashutosh Mestry, keval bhatt, Mandar Ambawane, > mayank jain, Nixon Rodrigues, Sarath Subramanian, and Sidharth Mishra. > > > Bugs: ATLAS-3611 > https://issues.apache.org/jira/browse/ATLAS-3611 > > > Repository: atlas > > > Description > --- > > added read-only field AtlasEntityDef.namespaceAttributes and populate it > while resolving references in type-registry > > > Diffs > - > > intg/src/main/java/org/apache/atlas/model/typedef/AtlasEntityDef.java > 14b3f03b0 > intg/src/main/java/org/apache/atlas/type/AtlasEntityType.java 02d6d58f1 > > > Diff: https://reviews.apache.org/r/72102/diff/1/ > > > Testing > --- > > - added couple of namespaces having attributes, and verified that the > attributes are added to namespaceAttributes in relevant AtlasEntityDef. > - pre-commit tests run: > https://builds.apache.org/view/A/view/Atlas/job/PreCommit-ATLAS-Build-Test/1624/ > > > Thanks, > > Madhan Neethiraj > >
[jira] [Created] (ATLAS-3612) Error while starting apache atlas
Balaji Mohanarangam created ATLAS-3612: -- Summary: Error while starting apache atlas Key: ATLAS-3612 URL: https://issues.apache.org/jira/browse/ATLAS-3612 Project: Atlas Issue Type: Bug Components: atlas-core Affects Versions: 0.8.4 Environment: NAME="CentOS Linux" VERSION="7 (Core)" Reporter: Balaji Mohanarangam Received the following error while starting atlas on an unix machine with default config. [root@xmdmpoc-as-1d apache-atlas-0.8.5-SNAPSHOT]# ./bin/atlas_start.py Exception: [Errno 2] No such file or directory Traceback (most recent call last): File "./bin/atlas_start.py", line 150, in File "./bin/atlas_start.py", line 74, in main File "/app/atlas/apache-atlas-0.8.5-SNAPSHOT/bin/atlas_config.py", line 149, i n expandWebApp jar(atlasWarPath) File "/app/atlas/apache-atlas-0.8.5-SNAPSHOT/bin/atlas_config.py", line 202, i n jar process = runProcess(commandline) File "/app/atlas/apache-atlas-0.8.5-SNAPSHOT/bin/atlas_config.py", line 238, i n runProcess p = subprocess.Popen(commandline, stdout=stdoutFile, stderr=stderrFile, shel l=shell) File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__ errread, errwrite) File "/usr/lib64/python2.7/subprocess.py", line 1327, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory -- This message was sent by Atlassian Jira (v8.3.4#803005)
Review Request 72104: Enable logging to STDOUT in Atlas startup scripts
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/72104/ --- Review request for atlas and Bolke de Bruin. Repository: atlas Description --- This patch enables logging to STDOUT from processes spawned through atlas_start.py or atlas_config.py scripts. For now, even if configured in log4j, logging to STDOUT was supressed (by redirecting to log files only). Diffs - distro/src/bin/atlas_config.py f09026ff9 distro/src/bin/atlas_start.py 963faf402 Diff: https://reviews.apache.org/r/72104/diff/1/ Testing --- The tests were concluded by: 1. Building & running Atlas locally with default log4j configuration and ENABLE_LOGGING_TO_CONSOLE variable set to true. 2. Building & running Atlas on Openshift with log4j configuration pushing everything to STDOUT and ENABLE_LOGGING_TO_CONSOLE variable set to true. In both scenarios logs were available both in the .out/.err files in the Atlas logdir (backwards compatibility), but at the same time I was able to see them in STDOUT of both running process (local installation) and pod (openshift deployment). Thanks, Mariusz Górski
[jira] [Updated] (ATLAS-3610) Enable logging to multiple targets (logdir, stdout)
[ https://issues.apache.org/jira/browse/ATLAS-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mariusz Górski updated ATLAS-3610: -- Description: *Problem description* When starting Atlas, Python scripts are invoked to spawn all necessary processes. This is achieved with the use of _subprocess.Popen()_ in _runProcess()_ function of _atlas_config.py_ script. While doing that, stdout is being redirected to log files, which (for java processes) can override log4j configuration (if configured with stdout handler). This creates situation when log4j configuration cannot be relied upon and prevents logging to stdout. *Proposed solution* * Add possibility to log to stdout by using multiple stdout/stderr handlers * Adjust _runProcess()_ function from _atlas_config.py_ script (and all functions relying on it) to provide _logconsole_ kwarg which will add additional handler to Popen stdout/stderr redirection * Add _ENABLE_LOGGING_TO_CONSOLE_ env variable (defaulting to _False_) for backwards compatibility. * Adjust _atlas_start.py_ script to make use of _ENABLE_LOGGING_TO_CONSOLE_ and provide it in functions invoking atlas/solr/elasticsearch/zookeeper *Predicted Benefits* This improvement would bring the benefit of enabling logging to stdout (which is supressed for now even if configured in spawned components), which could be very useful when running Atlas in docker container or in Kubernetes/OC, where some logging scraping is present. was: *Problem description* When starting Atlas, Python scripts are invoked to spawn all necessary processes. This is achieved with the use of _subprocess.Popen()_ in _runProcess()_ function of _atlas_config.py_ script. While doing that, stdout is being redirected to log files, which (for java processes) can override log4j configuration (if configured with stdout handler). This creates situation when log4j configuration cannot be relied upon and prevents logging to stdout. *Proposed solution* * Add possibility to log to stdout by using multiple stdout/stderr handlers * Adjust _runProcess()_ function from _atlas_config.py_ script (and all functions relying on it) to provide _logconsole_ kwarg which will add additional handler to Popen stdout/stderr redirection * Add _ENABLE_LOGGING_TO_CONSOLE_ env variable (defaulting to _False_) for backwards compatibility. * Adjust _atlas_start.py_ script to make use of _ENABLE_LOGGING_TO_CONSOLE_ and provide it in functions invoking atlas/solr/elasticsearch/zookeeper *Predicted Benefits* This improvement would bring the benefit of having single place where logging logic is defined (log4j config file) and enable logging to stdout, which could be very useful when running Atlas in docker container or in Kubernetes/OC, where some logging scraping is present. > Enable logging to multiple targets (logdir, stdout) > --- > > Key: ATLAS-3610 > URL: https://issues.apache.org/jira/browse/ATLAS-3610 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 3.0.0 >Reporter: Mariusz Górski >Priority: Minor > Fix For: 3.0.0 > > Attachments: ATLAS-3610.patch > > Time Spent: 50m > Remaining Estimate: 0h > > *Problem description* > When starting Atlas, Python scripts are invoked to spawn all necessary > processes. This is achieved with the use of _subprocess.Popen()_ in > _runProcess()_ function of _atlas_config.py_ script. While doing that, stdout > is being redirected to log files, which (for java processes) can override > log4j configuration (if configured with stdout handler). This creates > situation when log4j configuration cannot be relied upon and prevents logging > to stdout. > *Proposed solution* > * Add possibility to log to stdout by using multiple stdout/stderr handlers > * Adjust _runProcess()_ function from _atlas_config.py_ script (and all > functions relying on it) to provide _logconsole_ kwarg which will add > additional handler to Popen stdout/stderr redirection > * Add _ENABLE_LOGGING_TO_CONSOLE_ env variable (defaulting to _False_) for > backwards compatibility. > * Adjust _atlas_start.py_ script to make use of _ENABLE_LOGGING_TO_CONSOLE_ > and provide it in functions invoking atlas/solr/elasticsearch/zookeeper > *Predicted Benefits* > This improvement would bring the benefit of enabling logging to stdout (which > is supressed for now even if configured in spawned components), which could > be very useful when running Atlas in docker container or in Kubernetes/OC, > where some logging scraping is present. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ATLAS-3610) Enable logging to multiple targets (logdir, stdout)
[ https://issues.apache.org/jira/browse/ATLAS-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mariusz Górski updated ATLAS-3610: -- Attachment: (was: ATLAS-3610.patch) > Enable logging to multiple targets (logdir, stdout) > --- > > Key: ATLAS-3610 > URL: https://issues.apache.org/jira/browse/ATLAS-3610 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 3.0.0 >Reporter: Mariusz Górski >Priority: Minor > Fix For: 3.0.0 > > Attachments: ATLAS-3610.patch > > Time Spent: 50m > Remaining Estimate: 0h > > *Problem description* > When starting Atlas, Python scripts are invoked to spawn all necessary > processes. This is achieved with the use of _subprocess.Popen()_ in > _runProcess()_ function of _atlas_config.py_ script. While doing that, stdout > is being redirected to log files, which (for java processes) can override > log4j configuration (if configured with stdout handler). This creates > situation when log4j configuration cannot be relied upon and prevents logging > to stdout. > *Proposed solution* > * Add possibility to log to stdout by using multiple stdout/stderr handlers > * Adjust _runProcess()_ function from _atlas_config.py_ script (and all > functions relying on it) to provide _logconsole_ kwarg which will add > additional handler to Popen stdout/stderr redirection > * Add _ENABLE_LOGGING_TO_CONSOLE_ env variable (defaulting to _False_) for > backwards compatibility. > * Adjust _atlas_start.py_ script to make use of _ENABLE_LOGGING_TO_CONSOLE_ > and provide it in functions invoking atlas/solr/elasticsearch/zookeeper > *Predicted Benefits* > This improvement would bring the benefit of having single place where logging > logic is defined (log4j config file) and enable logging to stdout, which > could be very useful when running Atlas in docker container or in > Kubernetes/OC, where some logging scraping is present. -- This message was sent by Atlassian Jira (v8.3.4#803005)
