[jira] [Commented] (ATLAS-1773) Create the OMRS Connector for Atlas

[David Radley (JIRA)]

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

David Radley commented on ATLAS-1773:
-

[~grahamwallis] I wonder if you could add the link to this Jira to the 
associated RBT(s) for the latest patches. I assume you are looking for the RBTs 
to be reviewed

> Create the OMRS Connector for Atlas
> ---
>
> Key: ATLAS-1773
> URL: https://issues.apache.org/jira/browse/ATLAS-1773
> Project: Atlas
>  Issue Type: New Feature
>  Components:  atlas-core
>Affects Versions: 1.0.0
>Reporter: Mandy Chessell
>Assignee: Graham Wallis
>Priority: Major
> Attachments: ATLAS-1773-2018-12-21.patch, 
> ATLAS-2810-2019-01-10.patch, ATLAS-2939-2018-12-21.patch, 
> ATLAS-2985-2019-01-10.patch
>
>
> This JIRA provides the definition of the OMRS Connector API and an 
> implementation of this API for a local Apache Atlas metadata repository and 
> for the OMRS REST API.
> The OMRS Connector has 3 API groups
> * The types API - this is the metadata API for a metadata repository
> * The entity and relationships APIs that provide the type-agnostic interfaces 
> that can access any type - even those added dynamically
> * The fine-grained type-safe APIs that are generated from the addons models 
> in the build.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (ATLAS-2817) Update to JanusGraph 0.3.x

[David Radley (JIRA)]

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

David Radley edited comment on ATLAS-2817 at 8/23/18 8:01 AM:
--

[~apoorvnaik] I notice that Janus 0.3.0 
https://github.com/JanusGraph/janusgraph/releases
says it supports Apache HBase 1.2.6, 1.3.1, 1.4.4. In Atlas we are using HBase 
1.1. It looks like there is a mismatch. Also Atlas is using 5.5.1 and 
JanusGraph prereqs 5.5.4.

I have not checked that Cassandra ES levels that Atlas uses are compatible with 
this new level of JanusGraph.


was (Author: davidrad):
[~apoorvnaik] I notice that Janus 0.3.0 
https://github.com/JanusGraph/janusgraph/releases
says it supports Apache HBase 1.2.6, 1.3.1, 1.4.4. In Atlas we are using HBase 
1.1. It looks like there is a mismatch.

I have not checked that solr, Cassandra ES levels that Atlas uses are 
compatible with this new level of JanusGraph.

> Update to JanusGraph 0.3.x
> --
>
> Key: ATLAS-2817
> URL: https://issues.apache.org/jira/browse/ATLAS-2817
> Project: Atlas
>  Issue Type: Improvement
>Reporter: Apoorv Naik
>Assignee: Apoorv Naik
>Priority: Major
> Attachments: 0001-Janusgraph-update-to-0.3.0.patch
>
>
> There are couple of index related improvements in this version which helps 
> resolve the slowness in few of our DSL queries. This upgrade would speed up 
> DSL execution.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ATLAS-2817) Update to JanusGraph 0.3.x

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2817:
-

[~apoorvnaik] I notice that Janus 0.3.0 
https://github.com/JanusGraph/janusgraph/releases
says it supports Apache HBase 1.2.6, 1.3.1, 1.4.4. In Atlas we are using HBase 
1.1. It looks like there is a mismatch.

I have not checked that solr, Cassandra ES levels that Atlas uses are 
compatible with this new level of JanusGraph.

> Update to JanusGraph 0.3.x
> --
>
> Key: ATLAS-2817
> URL: https://issues.apache.org/jira/browse/ATLAS-2817
> Project: Atlas
>  Issue Type: Improvement
>Reporter: Apoorv Naik
>Assignee: Apoorv Naik
>Priority: Major
> Attachments: 0001-Janusgraph-update-to-0.3.0.patch
>
>
> There are couple of index related improvements in this version which helps 
> resolve the slowness in few of our DSL queries. This upgrade would speed up 
> DSL execution.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ATLAS-2774) Options for hard and soft delete of instances

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2774:
-

Sounds like a good change. A couple of thoughts:
- we may need to have new return codes if we attempt a purge and it does not 
work.
- I assume a soft delete of an entity soft deletes any associated relationships 
around it. I guess we may need special logic to handle deletion when there is a 
 composition relationship. It would make sense that deleting the container - 
deletes the children entities in this case (recursively) or is not allowed 
until the children are themselves deleted.

> Options for hard and soft delete of instances
> -
>
> Key: ATLAS-2774
> URL: https://issues.apache.org/jira/browse/ATLAS-2774
> Project: Atlas
>  Issue Type: New Feature
>Reporter: Graham Wallis
>Priority: Major
>
> *Overview*
> For Entities and Relationships, the following delete behaviors are desired.
> Atlas can be configured to offer hard delete (only). Alternatively it can be 
> configured to offer soft-delete. Configuration is achieved by setting the 
> delete handler configuration property (see atlas-application.properties) to 
> either the SoftDeleteHandlerV1 or the HardDeleteHandlerV1. The default (for 
> when the property is not set) is to use the SoftDeleteHandlerV1.
> The AtlasEntityStoreV2 deleteById() and deleteByIds() and methods and the 
> AtlasRelationshipStoreV2 deleteById() method are sensitive to the above 
> configuration. When the configuration is soft these methods will perform a 
> soft delete; when it is hard they will perform a hard delete.
> In addition to the above methods, the AtlasEntityStoreV2 and 
> AtlasRelationshipStoreV2 offer a (new) purgeById() method that ALWAYS 
> performs a hard delete. This is true regardless of which delete handler has 
> been configured. When the configuration is hard, the purgeById() methods and 
> deleteById() methods are essentially equivalent. When the configuration is 
> soft, the purgeById() methods continue to provide a hard delete capability.
> The AtlasEntityStoreV2 deleteById(), deleteByIds() and purgeById() methods 
> will delete the specified entities and any relationships to which they are 
> connected. The AtlasRelationshipStoreV2 deleteById() and purgeById() methods 
> will delete the specified relationship. Deletion of a relationship may cause 
> an upate to an entity to which the relationhsip is connected, if it changes 
> the propagation of classifications, for example.
> In a hard delete or purge operation, an affected entity and relationship will 
> be removed from the graph and will not be returned in response to any future 
> queries. This is true regardless of whether the affected entity or 
> relationship has already been soft deleted or not. i.e. it's status could 
> initially be ACTIVE or DELETED. Following the operation it will not exist.
> In a soft delete, the affected entities and relationships (that initially 
> have status ACTIVE) are updated to set the status to DELETED. These instances 
> can still be returned from queries and searches if the appropriate control is 
> selected (to include deleted instances). Without that control selected they 
> will not be returned.
> *Use Case for soft delete*
> Soft delete provides a 'safe' means of deleting instances from the repository 
> whilst preserving an audit trail and (if supported by the repository) 
> enabling a deleted instance to be restored (to ACTIVE status).
> *Use Cases for hard delete*
> One use case for hard delete is to permanently remove soft-deleted items some 
> period of time after they were soft deleted.
>  Another use case for hard delete is to is to correct (clean up after) a 
> mistake in which a potentially large batch of incomplete/corrupted/wrong 
> metadata is loaded and needs to be fully removed.
> *Use Scenario for an OMAS user*
> An OMAS provides a delete function that does NOT offer the user a choice of 
> hard/soft. The OMAS's delete function will invoke the relevant soft delete 
> method provided by the OMRS - deleteEntity or deleteRelationship. These are 
> both soft delete methods.
> The Atlas OMRS Connector's deleteEntity/deleteRelationship methods will check 
> whether Atlas is configured for hard or soft delete. If Atlas is configured 
> for hard delete then soft-delete is not possible, and the method will throw a 
> FunctionNotSupported exception which is caught by the OMAS.
> On catching this exception the OMAS author should automatically escalate the 
> soft delete to a hard delete by calling either of the mandatory OMRS 
> purgeEntity() or purgeRelationship() methods. In the Atlas OMRS Connector 
> these methods will invoke AtlasEntityStoreV2 purgeById() or 
> AtlasRelationshipStoreV2 

[jira] [Commented] (ATLAS-2708) AWS S3 data lake typedefs for Atlas

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2708:
-

[~barbara] I have had a quick look at the json file, it looks like you are 
using the old style of definition. I would recommend that that you use the new 
RelationshipDef style rather than constraints. This is more descriptive of 
relationships - it allows you to specify attributes on the relationship as 
well.  I think the constraints style is only there for so that the Hadoop types 
could continue to work.

> AWS S3 data lake typedefs for Atlas
> ---
>
> Key: ATLAS-2708
> URL: https://issues.apache.org/jira/browse/ATLAS-2708
> Project: Atlas
>  Issue Type: New Feature
>  Components:  atlas-core
>Reporter: Barbara Eckman
>Assignee: Barbara Eckman
>Priority: Critical
> Attachments: all_datalake_typedefs.json
>
>
> Currently the base types in Atlas do not include AWS data lake objects. It 
> would be nice to add typedefs for AWS data lake objects (buckets and 
> pseudo-directories) and lineage processes that move the data from another 
> source (e.g., kafka topic) to the data lake.  For example:
>  * AWSS3PseudoDir type represents the pseudo-directory “prefix” of objects in 
> an S3 bucket.  For example, in the case of an object with key 
> “myWork/Development/Projects1.xls”, “myWork/Development” is the 
> pseudo-directory.  It supports:
>  ** Array of avro schemas that are associated with the data in the 
> pseudo-directory (based on Avro schema extensions outlined in ATLAS-2694)
>  ** what type of data it contains, e.g., avro, json, unstructured
>  ** time of creation
>  * AWSS3BucketLifeCycleRule type represents a rule specifying a transition of 
> the data in a bucket to a storageClass after a specific time interval, or 
> expiration.  For example, transition to GLACIER after 60 days, or expire 
> (i.e. be deleted) after 90 days:
>  ** ruleType (e.g., transition or expiration)
>  ** time interval in days before rule is executed  
>  ** storageClass to which the data is transitioned (null if ruleType is 
> expiration)
>  * AWSTag type represents a tag-value pair created by the user and associated 
> with an AWS object.
>  **  tag
>  ** value
>  * AWSCloudWatchMetric type represents a storage or request metric that is 
> monitored by AWS CloudWatch and can be configured for a bucket
>  ** metricName, for example, “AllRequests”, “GetRequests”, 
> TotalRequestLatency, BucketSizeBytes
>  ** scope: null if entire bucket; otherwise, the prefixes/tags that filter or 
> limit the monitoring of the metric.
>  * AWSS3Bucket type represents a bucket in an S3 instance.  It supports:
>  ** Array of AWSS3PseudoDirectories that are associated with objects stored 
> in the bucket 
>  ** AWS region
>  ** IsEncrypted (boolean) 
>  ** encryptionType, e.g., AES-256
>  ** S3AccessPolicy, a JSON object expressing access policies, eg GetObject, 
> PutObject
>  ** time of creation
>  ** Array of AWSS3BucketLifeCycleRules that are associated with the bucket 
>  ** Array of AWSS3CloudWatchMetrics that are associated with the bucket or 
> its tags or prefixes
>  ** Array of AWSTags that are associated with the bucket
>  * Generic dataset2Dataset process to represent movement of data from one 
> dataset to another.  It supports:
>  ** array of transforms performed by the process 
>  ** map of tag/value pairs representing configurationParameters of the process
>  ** inputs and outputs are arrays of dataset objects, e.g., kafka topic and 
> S3 pseudo-directory.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ATLAS-1773) Create the OMRS Connector for Atlas

[David Radley (JIRA)]

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

David Radley commented on ATLAS-1773:
-

[~grahamwallis]  I have committed 2745. I then tried to follow the notes. I am 
on the latest master. The patch for ATLAS-1773 applied. 
I then ran 
git am < ATLAS-1773-2018-06-07.patch 
and got:
Applying: ATLAS-1773: Atlas OMRS Connector
✔ ~/atlasreview [master ↑·1|…2] 
09:20 $ git am < ATLAS-2665-Add-OMAG-API-in-Atlas-v7.patch 
Applying: ATLAS-2665 Add OMAG-API in Atlas
error: patch failed: omag-api/pom.xml:41
error: omag-api/pom.xml: patch does not apply
error: patch failed: omag-server/pom.xml:53
error: omag-server/pom.xml: patch does not apply
error: patch failed: omas-assetconsumer/pom.xml:39
error: omas-assetconsumer/pom.xml: patch does not apply
error: patch failed: omas-connectedasset/pom.xml:40
error: omas-connectedasset/pom.xml: patch does not apply
error: patch failed: omrs/pom.xml:39
error: omrs/pom.xml: patch does not apply
Patch failed at 0001 ATLAS-2665 Add OMAG-API in Atlas
The copy of the patch that failed is found in: .git/rebase-apply/patch

I did a 3 way merge choosing the patch content over head to apply the content. 
This was all around pom dependancies it did not like. This built successfully.
I got the log error even though I have made your suggested change (though 
possibly made a mistake). I have changed the omag-server pom to:

omag-server
Open Metadata and Governance (OMAG) Server

Open Metadata and Governance (OMAG) server for running open metadata 
function outside of the Apache Atlas server.


jar




org.springframework.boot
spring-boot-starter
1.5.7.RELEASE


ch.qos.logback
*





org.springframework.boot
spring-boot-starter-web
1.5.7.RELEASE

  

> Create the OMRS Connector for Atlas
> ---
>
> Key: ATLAS-1773
> URL: https://issues.apache.org/jira/browse/ATLAS-1773
> Project: Atlas
>  Issue Type: New Feature
>  Components:  atlas-core
>Affects Versions: 1.0.0
>Reporter: Mandy Chessell
>Assignee: Graham Wallis
>Priority: Major
> Attachments: ATLAS-1773-2018-06-07.patch, Notes on running the OMRS 
> stack including the Atlas OMRS connector.txt, 
> RELATIONSHIP_DEFS_AS_ASSOCIATIONS.patch
>
>
> This JIRA provides the definition of the OMRS Connector API and an 
> implementation of this API for a local Apache Atlas metadata repository and 
> for the OMRS REST API.
> The OMRS Connector has 3 API groups
> * The types API - this is the metadata API for a metadata repository
> * The entity and relationships APIs that provide the type-agnostic interfaces 
> that can access any type - even those added dynamically
> * The fine-grained type-safe APIs that are generated from the addons models 
> in the build.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (ATLAS-2745) Atlas EnumDefStore does not remember default value

[David Radley (JIRA)]

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

David Radley resolved ATLAS-2745.
-
Resolution: Fixed


commit ce5ffeb710721b78135e8b3c3ebe593bd70d2cdf (HEAD -> master, origin/master, 
origin/HEAD)
Author: Graham Wallis 
Date:   Thu Jun 7 14:25:53 2018 +0100

ATLAS-2745 - AtlasEnumDefStore should remember default value

Signed-off-by: David Radley 

> Atlas EnumDefStore does not remember default value
> --
>
> Key: ATLAS-2745
> URL: https://issues.apache.org/jira/browse/ATLAS-2745
> Project: Atlas
>  Issue Type: Bug
>Reporter: Graham Wallis
>Assignee: Graham Wallis
>Priority: Minor
> Attachments: ATLAS-2745-2018-06-07.patch
>
>
> If an enum def has a default value it is not remembered when the enum is 
> stored.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (ATLAS-2523) Import relationship, preserving existing GUID

[David Radley (JIRA)]

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

David Radley resolved ATLAS-2523.
-
Resolution: Fixed

commit 72cc566a7f23bef86c00afb6c7ef136c1d01b424 (HEAD -> master, origin/master, 
origin/HEAD)
Author: Graham Wallis 
Date:   Fri May 25 13:35:16 2018 +0100

ATLAS-2523 Add HomeId and allow GUIDs to be specified on creates

> Import relationship, preserving existing GUID
> -
>
> Key: ATLAS-2523
> URL: https://issues.apache.org/jira/browse/ATLAS-2523
> Project: Atlas
>  Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Graham Wallis
>Priority: Major
> Fix For: 1.0.0
>
> Attachments: ATLAS-2523-2018-05-25.patch
>
>
> To add a relationship defined externally (in another metadata repository), I 
> want to be able to add the relationship and maintain the existing GUID.
> This is possible for an entity by performing an import. It does not seem to 
> be possible for relationships., because the relationship store always 
> generates a new GUID, which overwrites the existing GUID.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (ATLAS-2665) Add OMAG-API in Atlas

[David Radley (JIRA)]

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

David Radley reassigned ATLAS-2665:
---

Assignee: Bogdan Sava

> Add OMAG-API in Atlas
> -
>
> Key: ATLAS-2665
> URL: https://issues.apache.org/jira/browse/ATLAS-2665
> Project: Atlas
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: Bogdan Sava
>Assignee: Bogdan Sava
>Priority: Major
> Attachments: 0001-ATLAS-2665-Add-OMAG-API-in-Atlas.patch
>
>
> Create configuration for OMAG API in Atlas using Spring MVC Dispatcher 
> servlet.
> Change base URL for the API to "/open-metadata/access-services" 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ATLAS-2674) Unable to set an array value for an attribute in the open metadata

[David Radley (JIRA)]

David Radley created ATLAS-2674:
---

 Summary: Unable to set an array value for an attribute in the open 
metadata
 Key: ATLAS-2674
 URL: https://issues.apache.org/jira/browse/ATLAS-2674
 Project: Atlas
  Issue Type: Improvement
  Components:  atlas-core
Reporter: David Radley
Assignee: David Radley


Unable to set an array value for an attribute in the open metadata



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ATLAS-2665) Add OMAG-API in Atlas

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2665:
-

Hi Bogdan - please can you combine the patches so they can be git pushed as one 
commit. 

> Add OMAG-API in Atlas
> -
>
> Key: ATLAS-2665
> URL: https://issues.apache.org/jira/browse/ATLAS-2665
> Project: Atlas
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: Bogdan Sava
>Priority: Major
> Attachments: 0001-ATLAS-2665-Add-OMAG-API-in-Atlas.patch, 
> 0002-ATLAS-2665-Added-apache-licence-to-properties-file.patch, 
> 0003-ATLAS-2665-comments-fixed.patch
>
>
> Create configuration for OMAG API in Atlas using Spring MVC Dispatcher 
> servlet.
> Change base URL for the API to "/open-metadata/access-services" 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ATLAS-2655) [Glossary] Restrict category child to be within same glossary

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2655:
-

It can be very useful to be able to have category children in other glossaries. 
For example re- using a 'standard' glossary categorizations across an 
organization.  
 If you need to restrict - could you put it under control of a feature toggle. 

> [Glossary] Restrict category child to be within same glossary
> -
>
> Key: ATLAS-2655
> URL: https://issues.apache.org/jira/browse/ATLAS-2655
> Project: Atlas
>  Issue Type: Bug
>Reporter: Apoorv Naik
>Assignee: Apoorv Naik
>Priority: Major
> Fix For: 1.0.0
>
>
> Currently no such check exists.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ATLAS-2607) Classification lifecycle through metadata properties and relationships

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2607:
-

[~madhan.neethiraj] . when you say "Asset can only be attached to 
classifications with the status of ACTIVE" -is this the general principle?

I had assumed that the Asset could be classified with a draft classification, 
this would exist in the graph but would not be seen by normal queries. We would 
need new queries that an workflow approver could use to see the draft 
classifications.

You say "Existing entity-classification-update permission will be used to 
enforce change to status". I suggest that the workflow permissions should be 
separate so we can have an approver that can only update the status and 
everyone else can update all but the status.  

In the open Metadata archive model I notice:
- there is a Draft sate in the open metadata TermRelationshipStatus. I wonder 
if you should consider using these enum values for classifications. 
- Open metadata also has the GovernanceClassificationStatus which includes 
states for Governance action classifications. 

It is worth considering enum states that will ease mapping from open metadata.. 




> Classification lifecycle through metadata properties and relationships
> --
>
> Key: ATLAS-2607
> URL: https://issues.apache.org/jira/browse/ATLAS-2607
> Project: Atlas
>  Issue Type: Improvement
>  Components:  atlas-core
>Reporter: Srikanth Venkat
>Assignee: Madhan Neethiraj
>Priority: Critical
>
> Currently tags or classifications in Atlas are considered active once they 
> are defined. For governance and stewardship purposes, it would be important 
> to attach the notion of what state in its lifecycle a particular 
> classification is. This would help with workflows to manage the lifecycle 
> aspects and provide any filtering needed to take appropriate actions. For 
> example only active classifications should be considered for classification 
> based policy enforcement. Additionally lifecycle status would help with 
> filtering and search as well as reporting and compliance/audit scenarios.
> Implementation Proposal:
>  * All tags or classifications have a "Lifecycle Status" property
>  * They can go through the following list of states during their lifecycle: 
> DRAFT -> ACTIVE  -> RETIRED
>  * Lifecycle Status can be set as an enum property that is mandatory or 
> required for all classifications.
>  * All existing classifications already present in Atlas before this change 
> will default to an ACTIVE status so that all pre-existing classifications 
> will continue to work as before.
>  * All new classifications after this change will start out with DRAFT status 
> and a steward or an admin with appropriate permissions can move them into an 
> ACTIVE state (controlled via Metadata security policies)
>  * Policy enforcement for authorization on classifications can ignore any 
> that are not in ACTIVE state. 
>  * Asset can only be attached to classifications with the status of ACTIVE
>  * For a classification in RETIRED state, we might have an optional 
> relationship with another classification called "Replaced By" which is the 
> new classification that the current one was remapped or replaced with. The 
> inverse relationship could be labeled "Replaces" which is on the new 
> classification and points to the removed classification that it replaces. 
>  * The state RETIRED implies this classification is no longer used and policy 
> enforcement will ignore any classifications in such states. 
>  * Additionally UI can filter and show by default only classifications that 
> are not RETIRED and a checkbox to "Show Retired"
>  * Deletion of classifications should work as it currently does with no 
> behavioral changes.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ATLAS-2139) Map IGC meta model and Atlas OMRS open metadata types

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2139:
-

[~sethv] Mandy is not available this week.

My thoughts on your questions are:
1. getSkeletonEntity is javadoc says "Return an entity with the header and type 
information filled out.  The caller only needs to add properties and 
classifications to complete the set up of the entity."  The way I am reading 
this is that I would not expect it to fill in properties, as the caller is 
expected to do this. 
2. The way the OMRS is, means that entities and relationships are created 
independently, but you need information from more than 1 entity or 
relationship, in order to issue the IGC call. If I have interpreted this 
correctly, my suggestion is :
- the IGC local connector keeps the entities and relationships until it has 
enough information (schema rids and the like) to issue the IGC request. Is 
there a way you can persist this information in IGC. 
or
-The local connector could query IGC for information that is not supplied in an 
add entity, this may allow you to access the rid information you need. 

   


> Map IGC meta model and Atlas OMRS open metadata types
> -
>
> Key: ATLAS-2139
> URL: https://issues.apache.org/jira/browse/ATLAS-2139
> Project: Atlas
>  Issue Type: Sub-task
>Reporter: Jerry He
>Assignee: Jerry He
>Priority: Major
> Attachments: Relational Tables and Columns.png
>
>
> Create the two-way mapping between IGC meta model and Atlas OMRS open 
> metadata types.
> It is used by the IGC Event Mapper and IGC metadata repository connector.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ATLAS-2622) Add extra checking for open metatdata entity type attributes

[David Radley (JIRA)]

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

David Radley updated ATLAS-2622:

Description: 
Jira 2604 added extra checking and units tests to ensure that relationshipdef 
enddef names do not conflict with each other or with any locally defined 
attributes. 

This Jira is raised to ensure that he same checking occurs for when add /update 
entitytype, add/update relationshipdefs are created via the API. 
Also this checking should occur when types are replicated between metadata 
repositories.

Ideally this and related name checking should be done in one place in the code 
for all these scenarios;  2604 updates code involved with the archive types 
only - I suggest this checking be pushed down into code that is used for the 
other scenarios if possible.

> Add extra checking for open metatdata entity type attributes
> 
>
> Key: ATLAS-2622
> URL: https://issues.apache.org/jira/browse/ATLAS-2622
> Project: Atlas
>  Issue Type: Improvement
>Reporter: David Radley
>Priority: Major
>
> Jira 2604 added extra checking and units tests to ensure that relationshipdef 
> enddef names do not conflict with each other or with any locally defined 
> attributes. 
> This Jira is raised to ensure that he same checking occurs for when add 
> /update entitytype, add/update relationshipdefs are created via the API. 
> Also this checking should occur when types are replicated between metadata 
> repositories.
> Ideally this and related name checking should be done in one place in the 
> code for all these scenarios;  2604 updates code involved with the archive 
> types only - I suggest this checking be pushed down into code that is used 
> for the other scenarios if possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ATLAS-2622) Add extra checking for open metatdata entity type attributes

[David Radley (JIRA)]

David Radley created ATLAS-2622:
---

 Summary: Add extra checking for open metatdata entity type 
attributes
 Key: ATLAS-2622
 URL: https://issues.apache.org/jira/browse/ATLAS-2622
 Project: Atlas
  Issue Type: Improvement
Reporter: David Radley






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ATLAS-2604) Minor fixups for relationshipdefs in the open metadata archive

[David Radley (JIRA)]

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

David Radley updated ATLAS-2604:

Attachment: ATLAS2604-3.patch

> Minor fixups for relationshipdefs in the open metadata archive 
> ---
>
> Key: ATLAS-2604
> URL: https://issues.apache.org/jira/browse/ATLAS-2604
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Radley
>Assignee: David Radley
>Priority: Major
> Attachments: ATLAS2604-2.patch, ATLAS2604-3.patch, ATLAS2604.patch
>
>
> Some relationships were introducing the same attribute name into an entity 
> type. This Jira is to change the relationshipdefs so all the entitydef 
> attributes are unique.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ATLAS-2604) Minor fixups for relationshipdefs in the open metadata archive

[David Radley (JIRA)]

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

David Radley updated ATLAS-2604:

Attachment: ATLAS2604-2.patch

> Minor fixups for relationshipdefs in the open metadata archive 
> ---
>
> Key: ATLAS-2604
> URL: https://issues.apache.org/jira/browse/ATLAS-2604
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Radley
>Assignee: David Radley
>Priority: Major
> Attachments: ATLAS2604-2.patch, ATLAS2604.patch
>
>
> Some relationships were introducing the same attribute name into an entity 
> type. This Jira is to change the relationshipdefs so all the entitydef 
> attributes are unique.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ATLAS-2604) Minor fixups for relationshipdefs in the open metadata archive

[David Radley (JIRA)]

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

David Radley updated ATLAS-2604:

Description: Some relationships were introducing the same attribute name 
into an entity type. This Jira is to change the relationshipdefs so all the 
entitydef attributes are unique.  (was: Some relationships were introducing the 
same attribute name into an entity type. This Jira is to change the 
relationships so all the entity attributes are unique.)

> Minor fixups for relationshipdefs in the open metadata archive 
> ---
>
> Key: ATLAS-2604
> URL: https://issues.apache.org/jira/browse/ATLAS-2604
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Radley
>Assignee: David Radley
>Priority: Major
> Attachments: ATLAS2604.patch
>
>
> Some relationships were introducing the same attribute name into an entity 
> type. This Jira is to change the relationshipdefs so all the entitydef 
> attributes are unique.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ATLAS-2604) Minor fixups for relationshipdefs in the open metadata archive

[David Radley (JIRA)]

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

David Radley updated ATLAS-2604:

Description: Some relationships were introducing the same attribute name 
into an entity type. This Jira is to change the relationships so all the entity 
attributes are unique.

> Minor fixups for relationshipdefs in the open metadata archive 
> ---
>
> Key: ATLAS-2604
> URL: https://issues.apache.org/jira/browse/ATLAS-2604
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Radley
>Assignee: David Radley
>Priority: Major
>
> Some relationships were introducing the same attribute name into an entity 
> type. This Jira is to change the relationships so all the entity attributes 
> are unique.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ATLAS-2604) Minor fixups for relationshipdefs in the open metadata archive

[David Radley (JIRA)]

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

David Radley updated ATLAS-2604:

Attachment: ATLAS2604.patch

> Minor fixups for relationshipdefs in the open metadata archive 
> ---
>
> Key: ATLAS-2604
> URL: https://issues.apache.org/jira/browse/ATLAS-2604
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Radley
>Assignee: David Radley
>Priority: Major
> Attachments: ATLAS2604.patch
>
>
> Some relationships were introducing the same attribute name into an entity 
> type. This Jira is to change the relationships so all the entity attributes 
> are unique.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ATLAS-2604) Minor fixups for relationshipdefs in the open metadata archive

[David Radley (JIRA)]

David Radley created ATLAS-2604:
---

 Summary: Minor fixups for relationshipdefs in the open metadata 
archive 
 Key: ATLAS-2604
 URL: https://issues.apache.org/jira/browse/ATLAS-2604
 Project: Atlas
  Issue Type: Bug
Reporter: David Radley
Assignee: David Radley






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ATLAS-2601) OMAG server Swagger

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2601:
-

[~daniela.otelea] . Ideally we should minimize the dependancies and standardise 
on one library to implement a capability. I am wondering why we need a new 
swagger dependancy - when we already have a working one knitted in the Atlas 
buld. .

omag-api is in the atlas web server - so this is not completely independent of 
Atlas.   

> OMAG server Swagger 
> 
>
> Key: ATLAS-2601
> URL: https://issues.apache.org/jira/browse/ATLAS-2601
> Project: Atlas
>  Issue Type: Improvement
>Reporter: Maryna Strelchuk
>Assignee: Maryna Strelchuk
>Priority: Major
> Attachments: 0001-Atlas-2601-OMAG-server-Swagger.patch
>
>
> This Jira addresses the addition of the Swagger for the OMAG server. 
> Currently Swagger was added as a dependency for
>  * omag-server
>  * omag-api
>  * omas-connectedasset



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ATLAS-2601) OMAG server Swagger

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2601:
-

The existing Atlas build uses enunciate to generate swagger. Is there a reason 
to add a second mechanism to generate Swagger? 

> OMAG server Swagger 
> 
>
> Key: ATLAS-2601
> URL: https://issues.apache.org/jira/browse/ATLAS-2601
> Project: Atlas
>  Issue Type: Improvement
>Reporter: Maryna Strelchuk
>Assignee: Maryna Strelchuk
>Priority: Major
> Attachments: 0001-Atlas-2601-OMAG-server-Swagger.patch
>
>
> This Jira addresses the addition of the Swagger for the OMAG server. 
> Currently Swagger was added as a dependency for
>  * omag-server
>  * omag-api
>  * omas-connectedasset



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ATLAS-2537) when running the omag server, by default it create files that interfere with a build

[David Radley (JIRA)]

David Radley created ATLAS-2537:
---

 Summary: when running the omag server, by default it create files 
that interfere with a build 
 Key: ATLAS-2537
 URL: https://issues.apache.org/jira/browse/ATLAS-2537
 Project: Atlas
  Issue Type: Improvement
Reporter: David Radley
Assignee: David Radley


when running the omagapplication in a development environment, by default a 
config file is created in the root of the workspace. This file causes build 
failures due to the licence checker and could also be inadvertently checked 
into git.

This Jira is raised to exclude this file in the license checker and to put it 
into .gitignore.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ATLAS-2478) Elasticsearch support is broken for JanusGraph

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2478:
-

[~ppadovani] I am not an expert on this part of Atlas. My thought is that most 
atlas customer will not have moved to Janus yet, so will need to perform some 
sort of migration of existing data; I would think that this sort of change 
could be made during the migration. 

The only released version of Atlas is an Alpha release, which is not intended 
for production. I suggest getting this change into master, so migration scripts 
could take account of this as well.  

> Elasticsearch support is broken for JanusGraph
> --
>
> Key: ATLAS-2478
> URL: https://issues.apache.org/jira/browse/ATLAS-2478
> Project: Atlas
>  Issue Type: Bug
>  Components:  atlas-core
>Affects Versions: 1.0.0-alpha
>Reporter: Pierre Padovani
>Assignee: Pierre Padovani
>Priority: Major
> Fix For: 1.0.0
>
>
> With JanusGraph the Elasticsearch support moved to 5.x+. This introduced a 
> change where fields that contained '.' (dots) were not allowed unless either 
> a specific cluster wide setting was enabled AND the mapping was formatted 
> such that each of the fields that contained a '.' could be considered part of 
> an object.
> Example:
> {code:java}
> foo.x
> foo.y
> foo.z{code}
>  Elasticsearch looks at these fields as if they are truly:
> {code:java}
> foo : {
>   x,
>   y,
>   z
> }{code}
> In the file:
> /atlas/common/src/main/java/org/apache/atlas/repository/Constants.java
> {code:java}
> /**
>  * Properties for type store graph.
>  */
> public static final String TYPE_CATEGORY_PROPERTY_KEY = 
> INTERNAL_PROPERTY_KEY_PREFIX + "type.category";
> public static final String VERTEX_TYPE_PROPERTY_KEY = 
> INTERNAL_PROPERTY_KEY_PREFIX + "type";
> public static final String TYPENAME_PROPERTY_KEY = 
> INTERNAL_PROPERTY_KEY_PREFIX + "type.name";
> public static final String TYPEDESCRIPTION_PROPERTY_KEY = 
> INTERNAL_PROPERTY_KEY_PREFIX + "type.description";
> public static final String TYPEVERSION_PROPERTY_KEY = 
> INTERNAL_PROPERTY_KEY_PREFIX + "type.version";
> public static final String TYPEOPTIONS_PROPERTY_KEY = 
> INTERNAL_PROPERTY_KEY_PREFIX + "type.options";
> {code}
> These are the only fields that cause Elasticsearch issue. As you can see a 
> field called 'type' is created, then additional fields type.name, 
> type.description etc. This will cause a mapping conflict exception in 
> Elasticsearch and it will refuse to create the mapping.
>  
> The easy fix is to simply replace the '.' with an '_' (underscore) but this 
> will be a backwards incompatible change for existing customers. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ATLAS-2465) OMRS - Kafka topic connector

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2465:
-

Hi [~kanes] ,

when you want the patch to be reviewed for inclusion into Atlas,  please create 
one patch file and put the same changes into the Review Board tool. The code 
reviews occur in the Review Board tool,  kind regards,   David.

 

> OMRS - Kafka topic connector 
> -
>
> Key: ATLAS-2465
> URL: https://issues.apache.org/jira/browse/ATLAS-2465
> Project: Atlas
>  Issue Type: Improvement
>  Components: atlas-intg
>Reporter: Shrinivas Kane
>Assignee: Shrinivas Kane
>Priority: Minor
> Attachments: kafka-topic_connector-part1.patch, 
> kafka-topic_connector-part2.patch
>
>
> Add topic connector which will 
> a) listen to incoming kafka message and distribute across listeners 
> b) send message to kafka topic based on generated events 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ATLAS-2259) Add Janus Graph Cassandra support

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2259:
-

Hi [~ppadovani], If you submit a patch I will review it and commit it for you 
if there are no concerns with it, this means submitting attaching a patch file 
to this Jira and raising a rbt review for the code,   all the best, David.  

> Add Janus Graph Cassandra support
> -
>
> Key: ATLAS-2259
> URL: https://issues.apache.org/jira/browse/ATLAS-2259
> Project: Atlas
>  Issue Type: Improvement
>  Components:  atlas-core
>Affects Versions: 1.0.0
>Reporter: Pierre Padovani
>Assignee: Pierre Padovani
>Priority: Major
> Fix For: 1.0.0
>
>
> Atlas should have support for Cassandra as a backend for Janus available by 
> default. If someone wants this type of configuration, they have to modify the 
> pom.xml and rebuild Atlas. Here is the pom.xml modification required to 
> enable this support:
> {code:java}
> 
> org.janusgraph
> janusgraph-cassandra
> ${janus.version}
> 
> 
> org.codehaus.jettison
> jettison
> 
> 
>   commons-lang
>   commons-lang
> 
> 
> 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ATLAS-2270) Supported combinations of persistent store and index backend

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2270:
-

Hi Pierre,
Great; you ask to be a contributer on the dev list - this allows you to 
assign a Jira to yourself.

Then you create a patch in git and attach it to the Jira and put it into 
the review board for review. There may be review comments or a "ship it". 
After that a committer (probably me in this case)  should take your patch 
and push it to master. 
 
I was new to git and have created a wiki page with the git commands I use 
https://cwiki.apache.org/confluence/display/ATLAS/Using+Git+with+Atlas. 
You may find this useful if you have not used git too much.
There is a also a wiki page for committers 
https://cwiki.apache.org/confluence/display/ATLAS/Developer+Resources you 
may be interested in . 

I suggest that the Jira should be scoped just to the fix you want to put 
in. You could change the words of 2270 or create a new one, 
   all the best, David. 




From:   "Pierre Padovani (JIRA)" 
To: david...@apache.org
Date:   22/02/2018 16:44
Subject:[jira] [Commented] (ATLAS-2270) Supported combinations of 
persistent store and index backend




[ 
https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_ATLAS-2D2270-3Fpage-3Dcom.atlassian.jira.plugin.system.issuetabpanels-3Acomment-2Dtabpanel-26focusedCommentId-3D16373048-23comment-2D16373048=DwICaQ=jf_iaSHvJObTbx-siA1ZOg=QhpUQPr5YlG95aAgCvZGStEXHg4hBbSYQ9JkRqR_svY=XQ5cRTBSZfDIanJGha8zM6Dkgnw0IjOYn8x5TlzRFBc=CvAzKNiTZy_yOqiqGZadB1tR74aieY28pWb2P8q3ucI=
 
] 

Pierre Padovani commented on ATLAS-2270:


[~davidrad] I'd be happy to be a contributor and get this in. How does one 
go about becoming one? Are there a set of guidelines somewhere specific to 
this project?

We've been running the Cassandra + ES 5.x flavor of Atlas as both a self 
contained docker container for dev purposes, as well as a full blown HA 
cluster for at least the last two months. So I think it looks like a 
pretty stable setup.

https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_ATLAS-2D2270=DwICaQ=jf_iaSHvJObTbx-siA1ZOg=QhpUQPr5YlG95aAgCvZGStEXHg4hBbSYQ9JkRqR_svY=XQ5cRTBSZfDIanJGha8zM6Dkgnw0IjOYn8x5TlzRFBc=r6UWXjJszzenyZwhDWtpds09zR_aEaPTnA245uXb-vU=

indexing backend Atlas 1.0.0 (master) should support. This includes 
building/running Atlas as a standalone package and running UTs/ITs as part 
of the Atlas build. 
databases that will be supported in master/1.0.0. This JIRA deliberately 
ignores titan1 and janusgraph 0.1.1 as the former should be 
deprecated/removed and the other is a transient state as we get to 
janusgraph 0.2.0. 
combinations of persistent store and indexer. It is suggested that this 
set is kept unchanged:
additional combinations. Cassandra is included in this discussion pending 
response to ATLAS-2259.
continued and the remaining 4 combinations, marked with '?', should be 
considered. There seems to be evidence of people using all 4 of these 
combinations, although not necessarily with Atlas.
possible to build Atlas as a standalone package with any of the 
combinations - i.e. that they are mutually exclusive and do not interfere 
with one another. They currently interfere which makes it impossible to 
build Atlas with -Pdist,berkeley-elasticsearch because the 'dist' profile 
will exclude jars that are needed by the berkeley-elasticsearch profile - 
which leads to class not found exceptions when the Atlas server is 
started. The solution to this could be very simple, or slightly more 
sophisticated, depending on how many of the combinations we choose to 
support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


> Supported combinations of persistent store and index backend
> 
>
> Key: ATLAS-2270
> URL: https://issues.apache.org/jira/browse/ATLAS-2270
> Project: Atlas
>  Issue Type: Bug
>Reporter: Graham Wallis
>Priority: Major
>
> We need to discuss and decide which combinations of persistent store and 
> indexing backend Atlas 1.0.0 (master) should support. This includes 
> building/running Atlas as a standalone package and running UTs/ITs as part of 
> the Atlas build. 
> This JIRA focusses on titan0 and janusgraph 0.2.0, as they are the graph 
> databases that will be supported in master/1.0.0. This JIRA deliberately 
> ignores titan1 and janusgraph 0.1.1 as the former should be 
> deprecated/removed and the other is a transient state as we get to janusgraph 
> 

[jira] [Commented] (ATLAS-2270) Supported combinations of persistent store and index backend

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2270:
-

[~ppadovani]  - as far as I am aware there is no one working on this at the 
moment. The only permutation that works is the Hbase solr one at the moment in 
master. You could become a contribute and contribute a fix, which we could 
commit.  I think in these situations the person who would like it in, needs to 
contribute the fix and would then fix any issues in that stack. At this time , 
this stack is not a priority at the moment for the few committers I have talked 
to. Is this patch something you want to contribute i.e. provide a patch to 
master and submit on the review board and be up for fixing any issues in that 
stack. I so I could commit it for you if it does not break the hbase solr 
config. 

> Supported combinations of persistent store and index backend
> 
>
> Key: ATLAS-2270
> URL: https://issues.apache.org/jira/browse/ATLAS-2270
> Project: Atlas
>  Issue Type: Bug
>Reporter: Graham Wallis
>Priority: Major
>
> We need to discuss and decide which combinations of persistent store and 
> indexing backend Atlas 1.0.0 (master) should support. This includes 
> building/running Atlas as a standalone package and running UTs/ITs as part of 
> the Atlas build. 
> This JIRA focusses on titan0 and janusgraph 0.2.0, as they are the graph 
> databases that will be supported in master/1.0.0. This JIRA deliberately 
> ignores titan1 and janusgraph 0.1.1 as the former should be 
> deprecated/removed and the other is a transient state as we get to janusgraph 
> 0.2.0. 
> With titan0 as the graph provider, Atlas has supported the following 
> combinations of persistent store and indexer. It is suggested that this set 
> is kept unchanged:
> {{
> titan0  solr  es
> 
> berkeley   0  1
> hbase   1  0
> cassandra0  0
> }}
> With janusgraph (0.2.0) as the graph provider, Atlas *could* support 
> additional combinations. Cassandra is included in this discussion pending 
> response to ATLAS-2259.
> {{
> janus 0.2.0  solr  es
> 
> berkeley   ?  1
> hbase   1  ?
> cassandra?  ?
> }}
> It is suggested that the combinations marked with '1' should be continued and 
> the remaining 4 combinations, marked with '?', should be considered. There 
> seems to be evidence of people using all 4 of these combinations, although 
> not necessarily with Atlas.
> Depending on the decision made above, we need to ensure that it is possible 
> to build Atlas as a standalone package with any of the combinations - i.e. 
> that they are mutually exclusive and do not interfere with one another. They 
> currently interfere which makes it impossible to build Atlas with 
> -Pdist,berkeley-elasticsearch because the 'dist' profile will exclude jars 
> that are needed by the berkeley-elasticsearch profile - which leads to class 
> not found exceptions when the Atlas server is started. The solution to this 
> could be very simple, or slightly more sophisticated, depending on how many 
> of the combinations we choose to support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ATLAS-2456) Implement tag propagation using relationships

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2456:
-

[~sarath.ku...@gmail.com] Thanks for your reply. 

>From your responses, is it true that: 
 * many propagated classifications of the same type can exist for an entity
 * a propagated classification can exist with the same type as an explicitly 
defined classification
 * on point 7 - does this mean that only one classification type or any of its 
sub types can be applied to an entity

 

I suggest:
 * we do not propagate a classification of a given type to an entity if there 
is already a classification of that type defined (we should account for sub 
types here)  
 * we should not allow more than one classification of a given type against an 
entity across explicitly defined classification and propagated classifications. 
This means that a policy only has to consider one classification and its 
ramifications. I am not sure how we resolve the potential conflicts; ideally 
this would be resolved using some rules and a  data steward. If we could search 
for these conflicts (maybe with a new conflicted status on the entity) , then a 
classification could be then explicitly defined on the entity and would force 
which classification values were effective.    

 

 

 

 

> Implement tag propagation using relationships
> -
>
> Key: ATLAS-2456
> URL: https://issues.apache.org/jira/browse/ATLAS-2456
> Project: Atlas
>  Issue Type: New Feature
>  Components:  atlas-core
>Affects Versions: 1.0.0
>Reporter: Sarath Subramanian
>Assignee: Sarath Subramanian
>Priority: Major
> Fix For: 1.0.0
>
> Attachments: TAG PROPAGATION IN ATLAS v.1.pdf, 
> tag_propagation_rest_api
>
>
> {color:#172b4d}Scalable way to quickly and efficiently propagate tags for 
> efficient searches and tag based security. Likewise tags for derivative 
> dataset should be inherited from the parent. For example, if an entity is 
> tagged "PII" then resulting entity created from a CTAS operation should also 
> be tagged "secret" to maintain the classification of the parent. In the case 
> where 2 or more datasets are aggregated the derivative dataset should be a 
> union of all parent tags.{color}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ATLAS-2456) Implement tag propagation using relationships

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2456:
-

[~sarath.ku...@gmail.com] I have not had time to go through the code in a lot 
of detail. I think it looks pretty good. I wanted to check how you handle the 
following situations:

1) If there is a classification that is applied to an entity with certain 
attributes defined, and you decide to propagate the same classification to that 
entity, in this situation there must be 2 classification instances - each with 
different property values. 

So how does the code handle the case when there are 2 instances of the same 
classification with different property values that propagate to the same target 
entity.

2) I think the classifications defined in the open type 
GovernanceActionclassifications 
[https://cwiki.apache.org/confluence/display/ATLAS/Area+4+-+Governance] are 
going to be the key classifications around governance. There classifications 
are defined by their enums- which have an implied low-high order.  So for 
example confifidentialityLevel of sensitive is higher than internal. For point 
1 scenario- we would want the higher value to win.    

4) I think that any classification that is explicitly defined on an entity wins 
over propagated values.

5) Can you confirm that only one classification of a type is allowed for a 
given entity.

6) I assume that the entitytypes defined on a classificationdef will always 
constrain - so classification and propagated classification (or their subtypes) 
can only ever classify entities of those types (or their subtypes). 

7) I assume that a classification and subtypes of a classification could both 
be applied to an entity. This could compromise the idea of one classification 
per entity. How do you see this working or is this policed as invalid?  For 
example a Confidentiality classification and its subclass could be applied to 
an entity. - each specifying different levels of confidentiality - which one is 
effective?

> Implement tag propagation using relationships
> -
>
> Key: ATLAS-2456
> URL: https://issues.apache.org/jira/browse/ATLAS-2456
> Project: Atlas
>  Issue Type: New Feature
>  Components:  atlas-core
>Affects Versions: 1.0.0
>Reporter: Sarath Subramanian
>Assignee: Sarath Subramanian
>Priority: Major
> Fix For: 1.0.0
>
> Attachments: TAG PROPAGATION IN ATLAS v.1.pdf, 
> tag_propagation_rest_api
>
>
> {color:#172b4d}Scalable way to quickly and efficiently propagate tags for 
> efficient searches and tag based security. Likewise tags for derivative 
> dataset should be inherited from the parent. For example, if an entity is 
> tagged "PII" then resulting entity created from a CTAS operation should also 
> be tagged "secret" to maintain the classification of the parent. In the case 
> where 2 or more datasets are aggregated the derivative dataset should be a 
> union of all parent tags.{color}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ATLAS-2246) Define OMRS Connector interface

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2246:
-

I have committed the code

commit 8a57e6571c0079c25c147732ad3a6994be8e14ea (HEAD -> master, origin/master, 
origin/HEAD)
Author: Mandy Chessell 
Date:   Thu Feb 15 12:46:01 2018 +

    ATLAS-2246: OMRS Connector API plus REST and IGC Connector skeleton - 15th 
February 2018
    
    Signed-off-by: David Radley 

> Define OMRS Connector interface
> ---
>
> Key: ATLAS-2246
> URL: https://issues.apache.org/jira/browse/ATLAS-2246
> Project: Atlas
>  Issue Type: Sub-task
>  Components: atlas-intg
>Reporter: Mandy Chessell
>Assignee: Mandy Chessell
>Priority: Critical
> Attachments: 
> 0001-ATLAS-2246-OMRS-Connector-API-plus-REST-and-IGC-Conn.patch, OMRS 
> Javadoc.zip
>
>
> This task covers the creation of the OMRS Connector APIs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ATLAS-2449) Latest master atlas does not build cleanly with tests enabled locally on Mac

[David Radley (JIRA)]

David Radley created ATLAS-2449:
---

 Summary: Latest master atlas does not build cleanly with tests 
enabled locally on Mac
 Key: ATLAS-2449
 URL: https://issues.apache.org/jira/browse/ATLAS-2449
 Project: Atlas
  Issue Type: Bug
Reporter: David Radley


I run mvn clean install -Pdist,embedded-hbase-solr

And it fails with:

127.0.0.1 - - [15/Feb/2018:14:06:01 +] "GET 
//localhost:31000/api/atlas/v2/types/typedef/name/hive_table_v1 HTTP/1.1" 503 
372 "-" "Java/1.8.0_151"
127.0.0.1 - - [15/Feb/2018:14:06:06 +] "GET 
//localhost:31000/api/atlas/v2/types/typedef/name/hive_table_v1 HTTP/1.1" 503 
372 "-" "Java/1.8.0_151"
127.0.0.1 - - [15/Feb/2018:14:06:11 +] "GET 
//localhost:31000/api/atlas/v2/types/typedef/name/hive_process_v1 HTTP/1.1" 503 
374 "-" "Java/1.8.0_151"
127.0.0.1 - - [15/Feb/2018:14:06:16 +] "GET 
//localhost:31000/api/atlas/v2/types/typedef/name/hive_process_v1 HTTP/1.1" 503 
374 "-" "Java/1.8.0_151"
127.0.0.1 - - [15/Feb/2018:14:06:21 +] "GET 
//localhost:31000/api/atlas/v2/types/typedef/name/hive_process_v1 HTTP/1.1" 503 
374 "-" "Java/1.8.0_151"
127.0.0.1 - - [15/Feb/2018:14:06:26 +] "GET 
//localhost:31000/api/atlas/v2/types/typedef/name/hive_process_v1 HTTP/1.1" 503 
374 "-" "Java/1.8.0_151"
127.0.0.1 - - [15/Feb/2018:14:06:31 +] "POST 
//localhost:31000/api/atlas/types HTTP/1.1" 503 342 "-" "Java/1.8.0_151"
127.0.0.1 - - [15/Feb/2018:14:06:36 +] "POST 
//localhost:31000/api/atlas/types HTTP/1.1" 503 342 "-" "Java/1.8.0_151"
127.0.0.1 - - [15/Feb/2018:14:06:41 +] "POST 
//localhost:31000/api/atlas/types HTTP/1.1" 503 342 "-" "Java/1.8.0_151"
127.0.0.1 - - [15/Feb/2018:14:06:46 +] "POST 
//localhost:31000/api/atlas/types HTTP/1.1" 503 342 "-" "Java/1.8.0_151"
Tests run: 143, Failures: 11, Errors: 0, Skipped: 125, Time elapsed: 2,422.962 
sec <<< FAILURE! - in TestSuite
setUp(org.apache.atlas.web.integration.DataSetLineageJerseyResourceIT)  Time 
elapsed: 510.086 sec  <<< FAILURE!
org.apache.atlas.AtlasServiceException: Metadata service API 
org.apache.atlas.AtlasClient$API_V1@5161ae92 failed with status 503 (Service 
Unavailable) Response Body (


Error 503 


HTTP ERROR: 503
Problem accessing /api/atlas/types. Reason:
    Service Unavailable
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.14.v20161028


)
    at 
org.apache.atlas.AtlasBaseClient.callAPIWithResource(AtlasBaseClient.java:388)
    at 
org.apache.atlas.AtlasBaseClient.callAPIWithResource(AtlasBaseClient.java:323)
    at org.apache.atlas.AtlasBaseClient.callAPI(AtlasBaseClient.java:211)
    at org.apache.atlas.AtlasClient.callAPIWithBody(AtlasClient.java:906)
    at org.apache.atlas.AtlasClient.createType(AtlasClient.java:257)
    at org.apache.atlas.AtlasClient.createType(AtlasClient.java:275)
    at 
org.apache.atlas.web.integration.BaseResourceIT.createType(BaseResourceIT.java:213)
    at 
org.apache.atlas.web.integration.BaseResourceIT.createTypeDefinitionsV1(BaseResourceIT.java:360)
    at 
org.apache.atlas.web.integration.DataSetLineageJerseyResourceIT.setUp(DataSetLineageJerseyResourceIT.java:60)

setUp(org.apache.atlas.notification.NotificationHookConsumerIT)  Time elapsed: 
362.578 sec  <<< FAILURE!
org.apache.atlas.AtlasServiceException: Metadata service API 
org.apache.atlas.AtlasClient$API_V1@5161ae92 failed with status 503 (Service 
Unavailable) Response Body (


Error 503 


HTTP ERROR: 503
Problem accessing /api/atlas/types. Reason:
    Service Unavailable
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.14.v20161028


)
    at 
org.apache.atlas.AtlasBaseClient.callAPIWithResource(AtlasBaseClient.java:388)
    at 
org.apache.atlas.AtlasBaseClient.callAPIWithResource(AtlasBaseClient.java:323)
    at org.apache.atlas.AtlasBaseClient.callAPI(AtlasBaseClient.java:211)
    at org.apache.atlas.AtlasClient.callAPIWithBody(AtlasClient.java:906)
    at org.apache.atlas.AtlasClient.createType(AtlasClient.java:257)
    at org.apache.atlas.AtlasClient.createType(AtlasClient.java:275)
    at 
org.apache.atlas.web.integration.BaseResourceIT.createType(BaseResourceIT.java:213)
    at 
org.apache.atlas.web.integration.BaseResourceIT.createTypeDefinitionsV1(BaseResourceIT.java:360)
    at 
org.apache.atlas.notification.NotificationHookConsumerIT.setUp(NotificationHookConsumerIT.java:54)

testAccessforUnauthenticatedResource(org.apache.atlas.web.filters.AtlasAuthenticationSimpleFilterIT)
  Time elapsed: 0.003 sec  <<< FAILURE!
java.lang.AssertionError: expected [200] but found [503]
    at org.testng.Assert.fail(Assert.java:94)
    at org.testng.Assert.failNotEquals(Assert.java:496)
    at org.testng.Assert.assertEquals(Assert.java:125)
    at org.testng.Assert.assertEquals(Assert.java:372)
    at org.testng.Assert.assertEquals(Assert.java:382)
    at 

[jira] [Commented] (ATLAS-1095) Open connector framework

[David Radley (JIRA)]

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

David Radley commented on ATLAS-1095:
-

I have committed the patch, the details are :

Author    Mandy Chessell     
    Fri, 19 Jan 2018 09:27:26 + (09:27 +)
committer    David Radley     
    Sat, 27 Jan 2018 00:40:56 + (00:40 +)
commit    cbfdd7fcc2ccb011c6f3000e3cb7a9de79268445
tree    bc710344fde1adac92c65ec74e1042cc34960db4    tree | snapshot
parent    804c4635e66e05fae627ad1e9344c1b11251ad35    commit | diff

> Open connector framework
> 
>
> Key: ATLAS-1095
> URL: https://issues.apache.org/jira/browse/ATLAS-1095
> Project: Atlas
>  Issue Type: New Feature
>Affects Versions: 1.0.0
>Reporter: Stephanie Hazlewood
>Assignee: David Radley
>Priority: Major
>  Labels: VirtualDataConnector
> Attachments: 0001-ATLAS-1095-final-code-drop-for-OCF.patch, OCF 
> JavaDoc.zip, Open Connector Framework - 20th June 2017.doc, Open Connector 
> Framework - 9th May 2017.doc
>
>
> Atlas provides a common approach to metadata management and governance across 
> all systems and data within an organization.  Today Atlas provides access to 
> metadata.   A connector provides access to a data source.  As connectors are 
> the proxy of all data, they can also be explicit providers of metadata.   
> This JIRA proposes an open connector framework to manage connectors that 
> provide access to both data and the metadata Atlas provides together through 
> a single connector interface.  
> This will help data tools to to better the exchange of information between 
> platforms. It also offers new opportunities for the consistent enforcement of 
> the governance policies and rules (e.g., rules of visibility).  Source 
> connector/connection metadata provides the nucleus around which all other 
> metadata describing the data builds.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ATLAS-2359) Bug in model Comment has 2 commentsOn fields

[David Radley (JIRA)]

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

David Radley updated ATLAS-2359:

Attachment: ATLAS2359.patch

> Bug in model Comment has 2 commentsOn fields
> 
>
> Key: ATLAS-2359
> URL: https://issues.apache.org/jira/browse/ATLAS-2359
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Radley
>Assignee: David Radley
> Attachments: ATLAS2359.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-2359) Bug in model Comment has 2 commentsOn fields

[David Radley (JIRA)]

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

David Radley updated ATLAS-2359:

Description: Change the 2nd commentsOn field to repliesOn

> Bug in model Comment has 2 commentsOn fields
> 
>
> Key: ATLAS-2359
> URL: https://issues.apache.org/jira/browse/ATLAS-2359
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Radley
>Assignee: David Radley
> Attachments: ATLAS2359.patch
>
>
> Change the 2nd commentsOn field to repliesOn



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (ATLAS-2359) Bug in model Comment has 2 commentsOn fields

[David Radley (JIRA)]

David Radley created ATLAS-2359:
---

 Summary: Bug in model Comment has 2 commentsOn fields
 Key: ATLAS-2359
 URL: https://issues.apache.org/jira/browse/ATLAS-2359
 Project: Atlas
  Issue Type: Bug
Reporter: David Radley
Assignee: David Radley






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-2341) Amend Atlas Area 1 model files so names are unique.

[David Radley (JIRA)]

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

David Radley updated ATLAS-2341:

Attachment: ATLAS2341-1.patch

> Amend Atlas Area 1 model files so names are unique.
> ---
>
> Key: ATLAS-2341
> URL: https://issues.apache.org/jira/browse/ATLAS-2341
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Radley
>Assignee: David Radley
> Attachments: ATLAS2341-1.patch, ATLAS2341.patch
>
>
> While working with the model files - I found that some of the relationship 
> end names are not unique. I think it is simpler to have these names unique. 
> This Jira is also used to remove some duplicated relationshipDef 
> "ProjectScope" and to add an empty attributeDef array for entityDef 
> "PrivateTag"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-2341) Amend Atlas Area 1 model files so names are unique.

[David Radley (JIRA)]

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

David Radley updated ATLAS-2341:

Attachment: ATLAS2341.patch

> Amend Atlas Area 1 model files so names are unique.
> ---
>
> Key: ATLAS-2341
> URL: https://issues.apache.org/jira/browse/ATLAS-2341
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Radley
>Assignee: David Radley
> Attachments: ATLAS2341.patch
>
>
> While working with the model files - I found that some of the relationship 
> end names are not unique. I think it is simpler to have these names unique. 
> This Jira is also used to remove some duplicated relationshipDef 
> "ProjectScope" and to add an empty attributeDef array for entityDef 
> "PrivateTag"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (ATLAS-2341) Amend Atlas Area 1 model files so names are unique.

[David Radley (JIRA)]

David Radley created ATLAS-2341:
---

 Summary: Amend Atlas Area 1 model files so names are unique.
 Key: ATLAS-2341
 URL: https://issues.apache.org/jira/browse/ATLAS-2341
 Project: Atlas
  Issue Type: Bug
Reporter: David Radley
Assignee: David Radley






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ATLAS-2298) OCF JDBC Connector for GaianDB

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2298:
-

[~Yao 22] Some initial comments on the design doc:

1) I would find it useful to understand the use cases for this connector.I 
assume the 2 main use cases are to query and to define new Logical tables (the 
new views), is adding GaianDB data sources in scope? 
2) It would be useful to see how the DB_ parameters map to the actual JDBC url 
that will be used.
3) I am wondering how the security works
   - are you using impersonation - if so how does this work?
   - if we are using certificates - does this connector need to know 
anything about them.   
4) It would be useful to understand and document what is assumed to be running 
and setup for the connector to work. 
 - I assume we need a running GaianDB instance.  
 - I assume the OCF needs to have the GaianDB connector defined. 


> OCF JDBC Connector for GaianDB
> --
>
> Key: ATLAS-2298
> URL: https://issues.apache.org/jira/browse/ATLAS-2298
> Project: Atlas
>  Issue Type: Improvement
>  Components:  atlas-core
>Reporter: Maryna Strelchuk
>Assignee: Yao Li
> Attachments: JDBC Connector Java Doc.zip, OCF JDBC Connector.pdf
>
>
> This Jira is focused on development of the OCF JDBC Connector for the GaianDB 
> which will be used to access data from GaianDB.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ATLAS-2298) OCF JDBC Connector for GaianDB

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2298:
-

[~Yao 22] I suggest adding the code that generates the jdbc javadoc into the 
review board tool - as this makes it easier to track issues.

Some initial comments on the javadoc :
1) I notice in the javadoc that JDBCConnectorErrorCode contains an extra /**
2) I notice public class ConnectionCheckedException extends 
JDBCConnectorCheckedExceptionBase. From the naming,  it is not obvious that 
ConnectionCheckedException has anything to do with JDBC from the name. 
3) The same for ExecutionCheckedException. 
4) to ease readability in 2 and 3 I suggest removing the checked from the names 
- as the runtime already indicated those exceptions are unchecked. 
 - renaming JDBCConnectorCheckedExceptionBase to JDBCConnectorException
 - renaming ConnectionCheckedException to ConnectionJDBCConnectorException
 - renaming ExecutionCheckedException to ExecutionJDBCConnectorException
5) In JDBCConnectorRuntimeException getReportedCaughtException() returns a 
Throwable - should this method be getReportedThrowable
6)  In JDBCConnectorRuntimeException getReportedSystemAction() - is this system 
action reported? I suggest removing the "reported" from the name. Same for 
"getReportedUserAction()" and "getReportedHTTPCode()"
7) Maybe rename GaianDBJDBCConnector to GaianJDBCConnector for readability
8)  For setDBUrlCreateFalse(java.lang.String realUserId) set up the proper 
database url, create is false. 
 - I suggest we pass a second boolean flag parameter rather than have 2 
methods.
 - what does create true and false mean?
 - what is the proper database?
 - what is the realUserId?
 - what does this mean "realUserId - used by the tempory GaianDB db url for 
authentication". What is temporary about this and what is real about it?
9) for ConnectionCheckedException - it says "there may be the odd bug that 
surfaces here." I suggest removing this. When should we use  
"JDBCConnectorErrorCode" and when should be use " messages defined uniquely for 
a ConnectorProvider/Connector implementation"




  


> OCF JDBC Connector for GaianDB
> --
>
> Key: ATLAS-2298
> URL: https://issues.apache.org/jira/browse/ATLAS-2298
> Project: Atlas
>  Issue Type: Improvement
>  Components:  atlas-core
>Reporter: Maryna Strelchuk
>Assignee: Yao Li
> Attachments: JDBC Connector Java Doc.zip, OCF JDBC Connector.pdf
>
>
> This Jira is focused on development of the OCF JDBC Connector for the GaianDB 
> which will be used to access data from GaianDB.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ATLAS-2327) Regression : Creating entity using V1 APIs with invalid values for attribute types succeeds

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2327:
-

I think the emphasis should be that we fix and enhance the V2 APIs; these are 
more functionally rich than the older V1 APIs. 
Note that the Jackson json parsing Atlas does, intentionally ignores json keys 
it does not recognise. If this is a mis spelt optional field, you may get 
behavour you do not expect..  

> Regression : Creating entity using V1 APIs with invalid values for attribute 
> types succeeds
> ---
>
> Key: ATLAS-2327
> URL: https://issues.apache.org/jira/browse/ATLAS-2327
> Project: Atlas
>  Issue Type: Bug
>  Components:  atlas-core
>Reporter: Sharmadha Sainath
>
> Creating an entity with invalid values using V1 APIs succeeds with 201. 
> Expected is 400 Bad Request. 
> This doesn't happen with V2 APIs. 
> Example :
> 1.Create type by posting JSON to /api/atlas/types
> 2.Create entity with random string value for float attribute by posting JSON 
> to /api/atlas/entities
> 3. Request succeeds with 201.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-2323) remove embedded media from term 0330 model

[David Radley (JIRA)]

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

David Radley updated ATLAS-2323:

Attachment: ATLAS2323.patch

> remove embedded media from term 0330 model
> --
>
> Key: ATLAS-2323
> URL: https://issues.apache.org/jira/browse/ATLAS-2323
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Radley
>Assignee: David Radley
> Attachments: ATLAS2323.patch
>
>
> There is an old style attribute in term relating to media. Is has the array 
> form. This needs to be removed - media relationships are defined in Area 0. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (ATLAS-2323) remove embedded media from term 0330 model

[David Radley (JIRA)]

David Radley created ATLAS-2323:
---

 Summary: remove embedded media from term 0330 model
 Key: ATLAS-2323
 URL: https://issues.apache.org/jira/browse/ATLAS-2323
 Project: Atlas
  Issue Type: Bug
Reporter: David Radley
Assignee: David Radley


There is an old style attribute in term relating to media. Is has the array 
form. This needs to be removed - media relationships are defined in Area 0. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ATLAS-2262) EntityGraphMapper update semantics

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2262:
-

[~grahamwallis] as we discussed - I suspect that your testing is using 
relationships based on AtlasRelationshipDefs defined with 
"isLegacyAttribute": true. I suggest testing with non legacy relationships as 
well - in this case there will be one edge for the relationship, I suspect we 
will then get the RelatedObjectIds and the relationship guid should then be 
used in matching. I suggest adding junits for these cases as well. 

We also discussed that in the Janus graph the edges always have a direction and 
the matching will need to be careful for ASSOCIATION relationship categories 
which at the entity level do not notionally have a direction.  

> EntityGraphMapper update semantics
> --
>
> Key: ATLAS-2262
> URL: https://issues.apache.org/jira/browse/ATLAS-2262
> Project: Atlas
>  Issue Type: Bug
>Reporter: Graham Wallis
>Assignee: Graham Wallis
>Priority: Minor
> Attachments: ATLAS-2262-v2.patch, ATLAS-2262-v3.patch, 
> ATLAS-2262-v4.patch, ATLAS-2262.patch
>
>
> Intermittent failures in AtlasRelationshipStoreV1Test occur during 
> modification of the 'friends' relationships between sample Employee and 
> Manager entities. 
> The intermittent failures are seen as different numbers of updated entities 
> being reported, which causes the test assertion to fail. The failures are 
> intermittent because they are caused by non-deterministic behaviour during 
> UPDATE of an entity's relationships. The non-determinism is caused by the 
> order in which results are returned by a graph query, although any order 
> should be considered valid.
> When built with graph provider titan0, the order of edges returned from the 
> graph is always the same, and the current EntityGraphMapper returns a 
> consistent result. The way it achieves it is slightly odd, with existing edge 
> reuse depending on the position of the edge in the returned list. But with 
> titan0, the behaviour is consistent, and correct.
> When using the janus graph provider, the order of edges returned from the 
> graph varies. This is valid behaviour on the part of the graph, but the 
> EntityGraphMapper does not behave the same when the edges are returned in a 
> different order compared to titan0.
> There are two levels of problem: The first is accuracy of the returned count 
> of updated entities; the second and in my opinion more important is the 
> semantics of an update operation that presents the same array of entity 
> relationships in an order that is not the same as the order returned by the 
> graph. In my opinion the result of the UPDATE operation should not vary 
> depending on the order of the edges returned by the internal graph query. If 
> the set of related entities presented matches the set already recorded then 
> the existing related entities should be reused, rather than replaced. It is 
> therefore the latter problem that I have been working on. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (ATLAS-1837) OCF definitions for Area 1 of the open metadata model

[David Radley (JIRA)]

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

David Radley edited comment on ATLAS-1837 at 12/18/17 4:50 PM:
---

[~Yao 22] It has moved to 
https://cwiki.apache.org/confluence/display/ATLAS/Area+2+-+Assets+and+Connectors
 . Area 1 is now collaboration.


was (Author: davidrad):
[~Yao 22] It has moved to 
https://cwiki.apache.org/confluence/display/ATLAS/Area+2+-+Assets+and+Connectors
 

> OCF definitions for Area 1 of the open metadata model
> -
>
> Key: ATLAS-1837
> URL: https://issues.apache.org/jira/browse/ATLAS-1837
> Project: Atlas
>  Issue Type: Task
>Reporter: Mandy Chessell
>Assignee: Mandy Chessell
>  Labels: OpenMetadata, VirtualDataConnector
>
> This task delivers the JSON files for the new models that describe types for 
> the open connector framework in Area 1 in the open metadata model.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ATLAS-1837) OCF definitions for Area 1 of the open metadata model

[David Radley (JIRA)]

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

David Radley commented on ATLAS-1837:
-

[~Yao 22] It has moved to 
https://cwiki.apache.org/confluence/display/ATLAS/Area+2+-+Assets+and+Connectors
 

> OCF definitions for Area 1 of the open metadata model
> -
>
> Key: ATLAS-1837
> URL: https://issues.apache.org/jira/browse/ATLAS-1837
> Project: Atlas
>  Issue Type: Task
>Reporter: Mandy Chessell
>Assignee: Mandy Chessell
>  Labels: OpenMetadata, VirtualDataConnector
>
> This task delivers the JSON files for the new models that describe types for 
> the open connector framework in Area 1 in the open metadata model.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ATLAS-2315) Atlas says it is successfully started even if the index engine is not working.

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2315:
-

Thanks for the pointer [~bpgergo]. This does look similar - I wanted to raise 
the wider issues in this Jira and agree potential approaches to resolve   

> Atlas says it is successfully started even if the index engine is not 
> working. 
> ---
>
> Key: ATLAS-2315
> URL: https://issues.apache.org/jira/browse/ATLAS-2315
> Project: Atlas
>  Issue Type: Bug
> Environment: Mac dev master
>Reporter: David Radley
>
> Atlas says it is successfully started even if the index engine is not 
> working. 
> Atlas does not check that that the index engine is working before saying that 
> Atlas has successfully started. 
> One way to handle this would be to have stages of initialization, including:
> - If embedded Hbase   
>- embedded backing store started 
>- embedded backing store accepting requests
> - If embedded index 
> - embedded index started
>- embedded index accepting requests 
> if not embedded index
>   - index engine verified to be active.
> - servlet engine started 
> - servlet engine accepting Rest calls
> Another approach would be to check that JanusGraph is sane prior to starting 
> Atlas and separating out any starting of embedded and verification of Janus 
> from any Atlas specific code. 
>  
> There needs to appropriate message so there is an obvious action to be taken 
> when the dependent components are not there when starting atlas using 
> atlas_start.py.   
> I am currently seeing issues when I have an Atlas built and running with 
> embedded Solr and Hbase and Janus. I then re build - the index / Hbase are 
> not cleaned up - so I get errors when attempting to start atlas again,all 
> the best, David.  
>   



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-2314) Minor fixups to Model files

[David Radley (JIRA)]

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

David Radley updated ATLAS-2314:

Description: 
Add the Glossary project to Area 3 .
Add the meetings models to Area1.
change the attached feedback to aggregation rather than composition
change the relationship category for community membership to association
add in commentReply relationship

Note this changes are being made in place, because these model files have not 
be been released yet. Once they are released, all changes need to be managed 
with versions and patches.  


  was:
Add the Glossary project to Area 3 .
Add the meetings models to Area1.
change the attached feedback to aggregation rather than composition
change the relationship category for community membership to association
add in commentReply relationship

Note this changes are being made in place, because these model files have not 
be been released yet. Once they are related all changes need to be managed with 
versions and patches.  



> Minor fixups to Model files
> ---
>
> Key: ATLAS-2314
> URL: https://issues.apache.org/jira/browse/ATLAS-2314
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Radley
>Assignee: David Radley
>
> Add the Glossary project to Area 3 .
> Add the meetings models to Area1.
> change the attached feedback to aggregation rather than composition
> change the relationship category for community membership to association
> add in commentReply relationship
> Note this changes are being made in place, because these model files have not 
> be been released yet. Once they are released, all changes need to be managed 
> with versions and patches.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (ATLAS-2315) Atlas says it is successfully started even if the index engine is not working.

[David Radley (JIRA)]

David Radley created ATLAS-2315:
---

 Summary: Atlas says it is successfully started even if the index 
engine is not working. 
 Key: ATLAS-2315
 URL: https://issues.apache.org/jira/browse/ATLAS-2315
 Project: Atlas
  Issue Type: Bug
 Environment: Mac dev master
Reporter: David Radley


Atlas says it is successfully started even if the index engine is not working. 

Atlas does not check that that the index engine is working before saying that 
Atlas has successfully started. 

One way to handle this would be to have stages of initialization, including:
- If embedded Hbase   
   - embedded backing store started 
   - embedded backing store accepting requests
- If embedded index 
- embedded index started
   - embedded index accepting requests 
if not embedded index
  - index engine verified to be active.
- servlet engine started 
- servlet engine accepting Rest calls

Another approach would be to check that JanusGraph is sane prior to starting 
Atlas and separating out any starting of embedded and verification of Janus 
from any Atlas specific code. 
 
There needs to appropriate message so there is an obvious action to be taken 
when the dependent components are not there when starting atlas using 
atlas_start.py.   

I am currently seeing issues when I have an Atlas built and running with 
embedded Solr and Hbase and Janus. I then re build - the index / Hbase are not 
cleaned up - so I get errors when attempting to start atlas again,all the 
best, David.  
  




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-2314) Minor fixups to Model files

[David Radley (JIRA)]

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

David Radley updated ATLAS-2314:

Description: 
Add the Glossary project to Area 3 .
Add the meetings models to Area1.
change the attached feedback to aggregation rather than composition
change the relationship category for community membership to association
add in commentReply relationship

Note this changes are being made in place, because these model files have not 
be been released yet. Once they are related all changes need to be managed with 
versions and patches.  


  was:
Add the Glossary project to Area 3 .
Add the meetings models to Area1.
change the attached feedback to aggregation rather than composition
change the relationship category for community membership to association
add in commentReply relationship


> Minor fixups to Model files
> ---
>
> Key: ATLAS-2314
> URL: https://issues.apache.org/jira/browse/ATLAS-2314
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Radley
>Assignee: David Radley
>
> Add the Glossary project to Area 3 .
> Add the meetings models to Area1.
> change the attached feedback to aggregation rather than composition
> change the relationship category for community membership to association
> add in commentReply relationship
> Note this changes are being made in place, because these model files have not 
> be been released yet. Once they are related all changes need to be managed 
> with versions and patches.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-2314) Minor fixups to Model files

[David Radley (JIRA)]

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

David Radley updated ATLAS-2314:

Description: 
Add the Glossary project to Area 3 .
Add the meetings models to Area1.
change the attached feedback to aggregation rather than composition
change the relationship category for community membership to association
add in commentReply relationship

> Minor fixups to Model files
> ---
>
> Key: ATLAS-2314
> URL: https://issues.apache.org/jira/browse/ATLAS-2314
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Radley
>Assignee: David Radley
>
> Add the Glossary project to Area 3 .
> Add the meetings models to Area1.
> change the attached feedback to aggregation rather than composition
> change the relationship category for community membership to association
> add in commentReply relationship



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (ATLAS-2314) Minor fixups to Model files

[David Radley (JIRA)]

David Radley created ATLAS-2314:
---

 Summary: Minor fixups to Model files
 Key: ATLAS-2314
 URL: https://issues.apache.org/jira/browse/ATLAS-2314
 Project: Atlas
  Issue Type: Bug
Reporter: David Radley
Assignee: David Radley






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-2309) Add Area 1 open metadata models

[David Radley (JIRA)]

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

David Radley updated ATLAS-2309:

Attachment: ATLAS2309.patch

> Add Area 1 open metadata models
> ---
>
> Key: ATLAS-2309
> URL: https://issues.apache.org/jira/browse/ATLAS-2309
> Project: Atlas
>  Issue Type: Improvement
>Reporter: David Radley
>Assignee: David Radley
> Attachments: ATLAS2309.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (ATLAS-2309) Add Area 1 open metadata models

[David Radley (JIRA)]

David Radley created ATLAS-2309:
---

 Summary: Add Area 1 open metadata models
 Key: ATLAS-2309
 URL: https://issues.apache.org/jira/browse/ATLAS-2309
 Project: Atlas
  Issue Type: Improvement
Reporter: David Radley
Assignee: David Radley






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-2306) Add Area 0 0045 model and other minor model amendments

[David Radley (JIRA)]

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

David Radley updated ATLAS-2306:

Attachment: ATLAS2306.patch

> Add Area 0 0045 model and other minor model amendments
> --
>
> Key: ATLAS-2306
> URL: https://issues.apache.org/jira/browse/ATLAS-2306
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Radley
>Assignee: David Radley
> Attachments: ATLAS2306.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (ATLAS-2306) Add Area 0 0045 model and other minor model amendments

[David Radley (JIRA)]

David Radley created ATLAS-2306:
---

 Summary: Add Area 0 0045 model and other minor model amendments
 Key: ATLAS-2306
 URL: https://issues.apache.org/jira/browse/ATLAS-2306
 Project: Atlas
  Issue Type: Bug
Reporter: David Radley
Assignee: David Radley






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-2303) Update Area 0 model in line with the latest wiki content

[David Radley (JIRA)]

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

David Radley updated ATLAS-2303:

Attachment: ATLAS2023.patch

> Update Area 0 model in line with the latest wiki content
> 
>
> Key: ATLAS-2303
> URL: https://issues.apache.org/jira/browse/ATLAS-2303
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Radley
>Assignee: David Radley
> Attachments: ATLAS2023.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-2303) Update Area 0 model in line with the latest wiki content

[David Radley (JIRA)]

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

David Radley updated ATLAS-2303:

Summary: Update Area 0 model in line with the latest wiki content  (was: 
Update model 0 in line with the latest wiki content)

> Update Area 0 model in line with the latest wiki content
> 
>
> Key: ATLAS-2303
> URL: https://issues.apache.org/jira/browse/ATLAS-2303
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Radley
>Assignee: David Radley
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (ATLAS-2303) Update model 0 in line with the latest wiki content

[David Radley (JIRA)]

David Radley created ATLAS-2303:
---

 Summary: Update model 0 in line with the latest wiki content
 Key: ATLAS-2303
 URL: https://issues.apache.org/jira/browse/ATLAS-2303
 Project: Atlas
  Issue Type: Bug
Reporter: David Radley
Assignee: David Radley






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-1828) Asset Catalog OMAS

[David Radley (JIRA)]

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

David Radley updated ATLAS-1828:

Summary: Asset Catalog OMAS  (was: Catalog OMAS)

> Asset Catalog OMAS
> --
>
> Key: ATLAS-1828
> URL: https://issues.apache.org/jira/browse/ATLAS-1828
> Project: Atlas
>  Issue Type: New Feature
>  Components:  atlas-core
>Affects Versions: 1.0.0
>Reporter: Mandy Chessell
>Assignee: Mandy Chessell
>  Labels: VirtualDataConnector
>
> This JIRA delivers the External API for catalog search applications.  This 
> API is used by ATLAS-1765 (https://issues.apache.org/jira/browse/ATLAS-1765) 
> that provides the Self-Service Catalog Search and Data Preview UI.
> This JIRA is dependent on ATLAS-1773 
> (https://issues.apache.org/jira/browse/ATLAS-1773) that implements the OMRS 
> REST Connector



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ATLAS-2270) Supported combinations of persistent store and index backend

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2270:
-

[~ppadovani] Thanks for your response. Some thoughts:

>From my understanding :
- Janus 0.2 only works with external solr and hbase. 

You will need to make Atlas code changes in order to run your configuration. 
The reasons Cassandra wont run at the moment include :
- the web app pom exclusions 
- at Janus 0.2 the indexing engine needs to be communicated to with rest and 
run separately to Janus. This meant that a separate solr indexing engine needs 
to be started. I guess you will need to work with a external elastic search 
engine. 
- you will need to ensure the created configuration matches the build. 

If you have questions/proposals regarding the current poms - we would be happy 
to feedback. 

There has been a Jira creating docker images as build output. It would be great 
if you could change the Atlas build to create docker images for your 
configuration. 

I suggest doing this Cassandra work in a separate Jira. 

As you think about how to add elastic search - it would be worth looking at the 
way the graph providers are specified in the build, in a similar way, my 
suggestion is that the choice of index engine and backing store are also 
cleanly specified with exclusivity in the poms.   

Another approach might be to re-add Janus 0.1.1 support - which was working for 
you. 
 

> Supported combinations of persistent store and index backend
> 
>
> Key: ATLAS-2270
> URL: https://issues.apache.org/jira/browse/ATLAS-2270
> Project: Atlas
>  Issue Type: Bug
>Reporter: Graham Wallis
>
> We need to discuss and decide which combinations of persistent store and 
> indexing backend Atlas 1.0.0 (master) should support. This includes 
> building/running Atlas as a standalone package and running UTs/ITs as part of 
> the Atlas build. 
> This JIRA focusses on titan0 and janusgraph 0.2.0, as they are the graph 
> databases that will be supported in master/1.0.0. This JIRA deliberately 
> ignores titan1 and janusgraph 0.1.1 as the former should be 
> deprecated/removed and the other is a transient state as we get to janusgraph 
> 0.2.0. 
> With titan0 as the graph provider, Atlas has supported the following 
> combinations of persistent store and indexer. It is suggested that this set 
> is kept unchanged:
> {{
> titan0  solr  es
> 
> berkeley   0  1
> hbase   1  0
> cassandra0  0
> }}
> With janusgraph (0.2.0) as the graph provider, Atlas *could* support 
> additional combinations. Cassandra is included in this discussion pending 
> response to ATLAS-2259.
> {{
> janus 0.2.0  solr  es
> 
> berkeley   ?  1
> hbase   1  ?
> cassandra?  ?
> }}
> It is suggested that the combinations marked with '1' should be continued and 
> the remaining 4 combinations, marked with '?', should be considered. There 
> seems to be evidence of people using all 4 of these combinations, although 
> not necessarily with Atlas.
> Depending on the decision made above, we need to ensure that it is possible 
> to build Atlas as a standalone package with any of the combinations - i.e. 
> that they are mutually exclusive and do not interfere with one another. They 
> currently interfere which makes it impossible to build Atlas with 
> -Pdist,berkeley-elasticsearch because the 'dist' profile will exclude jars 
> that are needed by the berkeley-elasticsearch profile - which leads to class 
> not found exceptions when the Atlas server is started. The solution to this 
> could be very simple, or slightly more sophisticated, depending on how many 
> of the combinations we choose to support.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ATLAS-2260) Ensure BerkeleyDB works with Janus

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2260:
-

[~jonesn] There are wider issues;  it looks like for all builds, the web app 
pom is excluding everything apart from Janus, hbase and solr. So for this 
reason, any attempt to use Berkeley, titan0 or ES will not work. Also Janus, 
hbase and solr does not work for me. 

[~grahamwallis] is talking with [~sarath.ku...@gmail.com] to agree a clean way 
to be able to build all the combinations we want to support. My feeling is that 
that Janus 2 package we bring in for a Berkeley build should contain everything 
it needs. 
  

> Ensure BerkeleyDB works with Janus 
> ---
>
> Key: ATLAS-2260
> URL: https://issues.apache.org/jira/browse/ATLAS-2260
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Radley
>
> currently Atlas defaults to JanusGraph in master. The Atlas build appears to 
> bring in the Apache 2 licensed BerkeleyDB JE 7.3.7. I should be possible for 
> Atlas to be built and run with Janus using this embedded BerkeleyDB. 
> Currently building with 
> mvn clean package -Pdist,berkeley-elasticsearch -DskipTests  
> is clean but Atlas fails to start - as it cannot find a sleepycat DBException 
> class.
> We should consider supporting running Berkeley with solr as well. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ATLAS-2265) Update jackson library to newer version

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2265:
-

[~madhan.neethiraj] I am not in a position to test this in a runtijme Atlas, 
but from some testing I did deserialising the models files notice that   


ObjectMapper mapper = new ObjectMapper()

.configure(DeserializationConfig.Feature.USE_BIG_DECIMAL_FOR_FLOATS, true);
to deserialise json.
then
   AtlasTypesDef typedDef = mapper.readValue(file, AtlasTypesDef.class);

Errors for unrecogised content. From what I understood, Atlas should ignore 
unrecognised json content by design. Please can you confirm whether after the 
library upgrade whether we tolerate unrecognised content or not and what the 
implications of a change here. It seems to me that we may need to add :
  mapper.configure(DeserializationConfig.Feature.FAIL_ON_UNKNOWN_PROPERTIES, 
false);
to ensure we tolerate unrecognised fields as we did before. 








> Update jackson library to newer version
> ---
>
> Key: ATLAS-2265
> URL: https://issues.apache.org/jira/browse/ATLAS-2265
> Project: Atlas
>  Issue Type: Bug
>  Components:  atlas-core, atlas-intg, atlas-webui
>Affects Versions: 1.0.0
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
> Fix For: 1.0.0
>
>
> Currently Atlas uses jackson library version 1.9.13, which is more than 4 
> years old. This usage should be updated to use latest jackson library 2.9.2. 
> Since version 2, jackson renamed package from org.codehaus.jackson to 
> com.fasterxml.jackson. This would require updates to sources that reference 
> org.codehause.jackson classes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (ATLAS-2270) Supported combinations of persistent store and index backend

[David Radley (JIRA)]

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

David Radley edited comment on ATLAS-2270 at 11/20/17 5:04 PM:
---

[~grahamwallis] thanks or raising this Jira. 
I suggest we consider: 
- do we support external or only embedded backing stores for titan0 and Janus. 
- The generated configs should work with the built code.
- ideally we should remove anything that the user cannot customise from the 
config. For example whether we are Titan0 or Janus, Solr or ES, Hbase or 
Berkeley. 
- All unsupported maven options should fail gracefully.
- we should remove all mention of titan1 and Janus 0.1.1. in the code, comments 
and docs. 
- all the above combinations should be considered in standalone and zookeeper 
mode.
- we should review all the configuration options and remove those that are not 
be applicable anymore. For example 
atlas.graph.storage.hbase.table=apache_atlas_titan does not seem to have a 
janus value. Is the commented out Type cache still valid? ",#Configures the 
graph database to use.  Defaults to JanusGraph 0.1.1" is incorrect in the 
config.
- graphdb readmes are incorrect and need to be updated to refer to Janus 0.2

 



was (Author: davidrad):
[~grahamwallis] thanks or raising this Jira. 
I suggest we consider: 
- do we support external or only imbedded backing stores for titan0 and Janus. 
- The generated configs should work with the built code.
- ideally we should remove anything that the user cannot customise from the 
config. For example whether we are Titan0 or Janus, Solr or ES, Hbase or 
Berkeley. 
- All unsupported maven options should fail gracefully.
- we should remove all mention of titan1 and Janus 0.1.1. in the code, comments 
and docs. 
- all the above combinations should be considered in standalone and zookeeper 
mode.
- we should review all the configuration options and remove those that are not 
be applicable anymore. For example 
atlas.graph.storage.hbase.table=apache_atlas_titan does not seem to have a 
janus value. Is the commented out Type cache still valid? ",#Configures the 
graph database to use.  Defaults to JanusGraph 0.1.1" is incorrect in the 
config.
- graphdb readmes are incorrect and need to be updated to refer to Janus 0.2

 


> Supported combinations of persistent store and index backend
> 
>
> Key: ATLAS-2270
> URL: https://issues.apache.org/jira/browse/ATLAS-2270
> Project: Atlas
>  Issue Type: Bug
>Reporter: Graham Wallis
>
> We need to discuss and decide which combinations of persistent store and 
> indexing backend Atlas 1.0.0 (master) should support. This includes 
> building/running Atlas as a standalone package and running UTs/ITs as part of 
> the Atlas build. 
> This JIRA focusses on titan0 and janusgraph 0.2.0, as they are the graph 
> databases that will be supported in master/1.0.0. This JIRA deliberately 
> ignores titan1 and janusgraph 0.1.1 as the former should be 
> deprecated/removed and the other is a transient state as we get to janusgraph 
> 0.2.0. 
> With titan0 as the graph provider, Atlas has supported the following 
> combinations of persistent store and indexer. It is suggested that this set 
> is kept unchanged:
> {{
> titan0  solr  es
> 
> berkeley   0  1
> hbase   1  0
> cassandra0  0
> }}
> With janusgraph (0.2.0) as the graph provider, Atlas *could* support 
> additional combinations. Cassandra is included in this discussion pending 
> response to ATLAS-2259.
> {{
> janus 0.2.0  solr  es
> 
> berkeley   ?  1
> hbase   1  ?
> cassandra?  ?
> }}
> It is suggested that the combinations marked with '1' should be continued and 
> the remaining 4 combinations, marked with '?', should be considered. There 
> seems to be evidence of people using all 4 of these combinations, although 
> not necessarily with Atlas.
> Depending on the decision made above, we need to ensure that it is possible 
> to build Atlas as a standalone package with any of the combinations - i.e. 
> that they are mutually exclusive and do not interfere with one another. They 
> currently interfere which makes it impossible to build Atlas with 
> -Pdist,berkeley-elasticsearch because the 'dist' profile will exclude jars 
> that are needed by the berkeley-elasticsearch profile - which leads to class 
> not found exceptions when the Atlas server is started. The solution to this 
> could be very simple, or slightly more sophisticated, depending on how many 
> of the combinations we choose to support.



--
This message was sent by Atlassian JIRA

[jira] [Comment Edited] (ATLAS-2270) Supported combinations of persistent store and index backend

[David Radley (JIRA)]

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

David Radley edited comment on ATLAS-2270 at 11/20/17 5:02 PM:
---

[~grahamwallis] thanks or raising this Jira. 
I suggest we consider: 
- do we support external or only imbedded backing stores for titan0 and Janus. 
- The generated configs should work with the built code.
- ideally we should remove anything that the user cannot customise from the 
config. For example whether we are Titan0 or Janus, Solr or ES, Hbase or 
Berkeley. 
- All unsupported maven options should fail gracefully.
- we should remove all mention of titan1 and Janus 0.1.1. in the code, comments 
and docs. 
- all the above combinations should be considered in standalone and zookeeper 
mode.
- we should review all the configuration options and remove those that are not 
be applicable anymore. For example 
atlas.graph.storage.hbase.table=apache_atlas_titan does not seem to have a 
janus value. Is the commented out Type cache still valid? ",#Configures the 
graph database to use.  Defaults to JanusGraph 0.1.1" is incorrect in the 
config.
- graphdb readmes are incorrect and need to be updated to refer to Janus 0.2

 



was (Author: davidrad):
[~grahamwallis] thanks or raising this Jira. 
I suggest we consider: 
- do we support external or only imbedded backing stores for titan0 and Janus. 
- The generated configs should work with the built code.
- ideally we should remove anything that the user cannot customise from the 
config. For example whether we are Titan0 or Janus, Solr or ES, Hbase or 
Berkeley. 
- All unsupported maven options should fail gracefully.
- we should remove all mention of titan1 and Janus 0.1.1. in the code, comments 
and docs. 
 


> Supported combinations of persistent store and index backend
> 
>
> Key: ATLAS-2270
> URL: https://issues.apache.org/jira/browse/ATLAS-2270
> Project: Atlas
>  Issue Type: Bug
>Reporter: Graham Wallis
>
> We need to discuss and decide which combinations of persistent store and 
> indexing backend Atlas 1.0.0 (master) should support. This includes 
> building/running Atlas as a standalone package and running UTs/ITs as part of 
> the Atlas build. 
> This JIRA focusses on titan0 and janusgraph 0.2.0, as they are the graph 
> databases that will be supported in master/1.0.0. This JIRA deliberately 
> ignores titan1 and janusgraph 0.1.1 as the former should be 
> deprecated/removed and the other is a transient state as we get to janusgraph 
> 0.2.0. 
> With titan0 as the graph provider, Atlas has supported the following 
> combinations of persistent store and indexer. It is suggested that this set 
> is kept unchanged:
> {{
> titan0  solr  es
> 
> berkeley   0  1
> hbase   1  0
> cassandra0  0
> }}
> With janusgraph (0.2.0) as the graph provider, Atlas *could* support 
> additional combinations. Cassandra is included in this discussion pending 
> response to ATLAS-2259.
> {{
> janus 0.2.0  solr  es
> 
> berkeley   ?  1
> hbase   1  ?
> cassandra?  ?
> }}
> It is suggested that the combinations marked with '1' should be continued and 
> the remaining 4 combinations, marked with '?', should be considered. There 
> seems to be evidence of people using all 4 of these combinations, although 
> not necessarily with Atlas.
> Depending on the decision made above, we need to ensure that it is possible 
> to build Atlas as a standalone package with any of the combinations - i.e. 
> that they are mutually exclusive and do not interfere with one another. They 
> currently interfere which makes it impossible to build Atlas with 
> -Pdist,berkeley-elasticsearch because the 'dist' profile will exclude jars 
> that are needed by the berkeley-elasticsearch profile - which leads to class 
> not found exceptions when the Atlas server is started. The solution to this 
> could be very simple, or slightly more sophisticated, depending on how many 
> of the combinations we choose to support.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ATLAS-2270) Supported combinations of persistent store and index backend

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2270:
-

[~grahamwallis] thanks or raising this Jira. 
I suggest we consider: 
- do we support external or only imbedded backing stores for titan0 and Janus. 
- The generated configs should work with the built code.
- ideally we should remove anything that the user cannot customise from the 
config. For example whether we are Titan0 or Janus, Solr or ES, Hbase or 
Berkeley. 
- All unsupported maven options should fail gracefully.
- we should remove all mention of titan1 and Janus 0.1.1. in the code, comments 
and docs. 
 


> Supported combinations of persistent store and index backend
> 
>
> Key: ATLAS-2270
> URL: https://issues.apache.org/jira/browse/ATLAS-2270
> Project: Atlas
>  Issue Type: Bug
>Reporter: Graham Wallis
>
> We need to discuss and decide which combinations of persistent store and 
> indexing backend Atlas 1.0.0 (master) should support. This includes 
> building/running Atlas as a standalone package and running UTs/ITs as part of 
> the Atlas build. 
> This JIRA focusses on titan0 and janusgraph 0.2.0, as they are the graph 
> databases that will be supported in master/1.0.0. This JIRA deliberately 
> ignores titan1 and janusgraph 0.1.1 as the former should be 
> deprecated/removed and the other is a transient state as we get to janusgraph 
> 0.2.0. 
> With titan0 as the graph provider, Atlas has supported the following 
> combinations of persistent store and indexer. It is suggested that this set 
> is kept unchanged:
> {{
> titan0  solr  es
> 
> berkeley   0  1
> hbase   1  0
> cassandra0  0
> }}
> With janusgraph (0.2.0) as the graph provider, Atlas *could* support 
> additional combinations. Cassandra is included in this discussion pending 
> response to ATLAS-2259.
> {{
> janus 0.2.0  solr  es
> 
> berkeley   ?  1
> hbase   1  ?
> cassandra?  ?
> }}
> It is suggested that the combinations marked with '1' should be continued and 
> the remaining 4 combinations, marked with '?', should be considered. There 
> seems to be evidence of people using all 4 of these combinations, although 
> not necessarily with Atlas.
> Depending on the decision made above, we need to ensure that it is possible 
> to build Atlas as a standalone package with any of the combinations - i.e. 
> that they are mutually exclusive and do not interfere with one another. They 
> currently interfere which makes it impossible to build Atlas with 
> -Pdist,berkeley-elasticsearch because the 'dist' profile will exclude jars 
> that are needed by the berkeley-elasticsearch profile - which leads to class 
> not found exceptions when the Atlas server is started. The solution to this 
> could be very simple, or slightly more sophisticated, depending on how many 
> of the combinations we choose to support.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (ATLAS-2269) Errors in the Area 0 and 3 models shown up by the latest Jackson libraries

[David Radley (JIRA)]

David Radley created ATLAS-2269:
---

 Summary: Errors in the Area 0 and 3 models shown up by the latest 
Jackson libraries
 Key: ATLAS-2269
 URL: https://issues.apache.org/jira/browse/ATLAS-2269
 Project: Atlas
  Issue Type: Bug
Reporter: David Radley
Assignee: David Radley


while playing with serializing the models, I notice that the latest Jackson 
libraries check json more strictly against the java class it is deserializing 
to. This has uncovered some errors in the json models. 





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (ATLAS-2261) Atlas cannot be built with Titan0 on master with BerkeleyDB

[David Radley (JIRA)]

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

David Radley edited comment on ATLAS-2261 at 11/17/17 11:28 AM:


[~grahamwallis] That did not work for me .

It seems I need to add in this line or Atlas does not know to generate titan0: 
atlas.graphdb.backend=org.apache.atlas.repository.graphdb.titan0.Titan0GraphDatabase
With this addition it now starts and and accept rest requests. 

[~madhan.neethiraj] I think we should remove all the configuration from the 
atals-application.properties file that the user should not change. 
In the case where we build with Titan0 - it is not possible to run Janus- so 
the code should just work using titan0. 
In the case where we build with Berkeleyje -we should not put this in the 
configuration file - as no other value could work with the code we build. We 
should leave in properties that the user can customize.  What do you think?
  





was (Author: davidrad):
[~grahamwallis] That did not work for me .

It seems I need to add in this line or Atlas does not know to generate titan0: 
atlas.graphdb.backend=org.apache.atlas.repository.graphdb.titan0.Titan0GraphDatabase
 
[~madhan.neethiraj] I think we should remove all the configuration from the 
atals-application.properties file that the user should not change. 
In the case where we build with Titan0 - it is not possible to run Janus- so 
the code should just work using titan0. 
In the case where we build with Berkeleyje -we should not put this in the 
configuration file - as no other value could work with the code we build. We 
should leave in properties that the user can customize.  What do you think?
  




> Atlas cannot be built with Titan0 on master with BerkeleyDB
> ---
>
> Key: ATLAS-2261
> URL: https://issues.apache.org/jira/browse/ATLAS-2261
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Radley
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ATLAS-2261) Atlas cannot be built with Titan0 on master with BerkeleyDB

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2261:
-

[~grahamwallis] That did not work for me .

It seems I need to add in this line or Atlas does not know to generate titan0: 
atlas.graphdb.backend=org.apache.atlas.repository.graphdb.titan0.Titan0GraphDatabase
 
[~madhan.neethiraj] I think we should remove all the configuration from the 
atals-application.properties file that the user should not change. 
In the case where we build with Titan0 - it is not possible to run Janus- so 
the code should just work using titan0. 
In the case where we build with Berkeleyje -we should not put this in the 
configuration file - as no other value could work with the code we build. We 
should leave in properties that the user can customize.  What do you think?
  




> Atlas cannot be built with Titan0 on master with BerkeleyDB
> ---
>
> Key: ATLAS-2261
> URL: https://issues.apache.org/jira/browse/ATLAS-2261
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Radley
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ATLAS-2261) Atlas cannot be built with Titan0 on master with BerkeleyDB

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2261:
-

Thanks [~grahamwallis] - I will give this circumvention a go. 

> Atlas cannot be built with Titan0 on master with BerkeleyDB
> ---
>
> Key: ATLAS-2261
> URL: https://issues.apache.org/jira/browse/ATLAS-2261
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Radley
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (ATLAS-2261) Atlas cannot be built with Titan0 on master with BerkeleyDB

[David Radley (JIRA)]

David Radley created ATLAS-2261:
---

 Summary: Atlas cannot be built with Titan0 on master with 
BerkeleyDB
 Key: ATLAS-2261
 URL: https://issues.apache.org/jira/browse/ATLAS-2261
 Project: Atlas
  Issue Type: Bug
Reporter: David Radley






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (ATLAS-2260) Ensure BerkeleyDB works with Janus

[David Radley (JIRA)]

David Radley created ATLAS-2260:
---

 Summary: Ensure BerkeleyDB works with Janus 
 Key: ATLAS-2260
 URL: https://issues.apache.org/jira/browse/ATLAS-2260
 Project: Atlas
  Issue Type: Bug
Reporter: David Radley


currently Atlas defaults to JanusGraph in master. The Atlas build appears to 
bring in the Apache 2 licensed BerkeleyDB JE 7.3.7. I should be possible for 
Atlas to be built and run with Janus using this embedded BerkeleyDB. Currently 
building with 
mvn clean package -Pdist,berkeley-elasticsearch -DskipTests  
is clean but Atlas fails to start - as it cannot find a sleepycat DBException 
class.

We should consider supporting running Berkeley with solr as well. 




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ATLAS-2084) Make berkeley DB backed Atlas available without external download

[David Radley (JIRA)]

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

David Radley commented on ATLAS-2084:
-

[~jonesn] I agree - I suggest closing this Jira. I think the effort should be 
to ensure we can use the imbedded berkeleydb that is already in the build with 
Janus.  


> Make berkeley DB backed Atlas available without external download
> -
>
> Key: ATLAS-2084
> URL: https://issues.apache.org/jira/browse/ATLAS-2084
> Project: Atlas
>  Issue Type: Improvement
>Reporter: Nigel Jones
>Assignee: Nigel Jones
> Attachments: ATLAS_2084_Add_BerkeleyDB_libraries.patch
>
>
> In https://issues.apache.org/jira/browse/ATLAS-2012 I proposed providing a 
> dockerized version of Atlas to aid people getting up to speed with the 
> technology. During the review it was noted that we had used Hbase for storage 
> rather than the more lightweight, simpler, BerkeleyDB. My concern had been 
> around licensing.
> Today when we build Atlas following the instructions at 
> http://atlas.apache.org/InstallationSteps.html the user is directed to 
> download the berkeleyDB jar from oracle. In ATLAS-2012 David/Graham pointed 
> out that this DB appears to be Apache 2.0 licensed, which means we could 
> incorporate it into our build legitimately.
> Given the necessity to get licensing correct I've opened up this new JIRA to 
> focus on that change. We would need to
>  * Validate we are indeed correct about the license
>  * Add the DB file into the build
>  * Update the web instructions
>  * And optionally as per the original JIRA, consider making B-DB the default 
> for our docker image (most lightweight).
> Please add your thoughts. I'm happy to get and do this change .



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (ATLAS-2233) Java 8 no longer supports MaxPermSize -- noise in logs

[David Radley (JIRA)]

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

David Radley resolved ATLAS-2233.
-
Resolution: Fixed

Commit: 1869aee3dcf1d5a073c79292fa2442d3f829774c

> Java 8 no longer supports MaxPermSize -- noise in logs
> --
>
> Key: ATLAS-2233
> URL: https://issues.apache.org/jira/browse/ATLAS-2233
> Project: Atlas
>  Issue Type: Improvement
>Reporter: Nigel Jones
>Assignee: Nigel Jones
>Priority: Major
> Attachments: ATLAS-2233.patch, Screen Shot 2017-10-26 at 12.56.54.png
>
>
> Now that we only support Java 8 we should remove references to 
> -XX:MaxPermSize in the poms, scripts, documents, wiki.
> The build log is littered with
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512m; 
> support was removed in 8.0
> The included image gives the results of a quick search



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-1698) Create Subject Area OMAS API

[David Radley (JIRA)]

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

David Radley updated ATLAS-1698:

Attachment: Subject Area OMAS API proposal v1.5.pdf

> Create Subject Area OMAS API
> 
>
> Key: ATLAS-1698
> URL: https://issues.apache.org/jira/browse/ATLAS-1698
> Project: Atlas
>  Issue Type: Sub-task
>Reporter: David Radley
>Assignee: David Radley
>  Labels: VirtualDataConnector
> Attachments: ATLAS1698-1.patch, ATLAS1698.patch, Atlas Glossary OMAS 
> API proposal v1.0 .pdf, Atlas Glossary OMAS API proposal v1.1.pdf, Atlas 
> Glossary OMAS API proposal v1.2.pdf, Subject Area OMAS API proposal v1.3.pdf, 
> Subject Area OMAS API proposal v1.4.pdf, Subject Area OMAS API proposal 
> v1.5.pdf, apidocs-1.zip, apidocs.zip
>
>
> The Subject Area OMAS provides a specialized API for glossary applications to 
> retrieve and store their glossary metadata and link assets of different types 
> to these glossary entries.
> The Subject Area OMAS makes heavy use of the Area 3 open metadata model.  See 
> https://issues.apache.org/jira/browse/ATLAS-1840



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-1698) Create Subject Area OMAS API

[David Radley (JIRA)]

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

David Radley updated ATLAS-1698:

Attachment: Subject Area OMAS API proposal v1.4.pdf

Added story board for UI

> Create Subject Area OMAS API
> 
>
> Key: ATLAS-1698
> URL: https://issues.apache.org/jira/browse/ATLAS-1698
> Project: Atlas
>  Issue Type: Sub-task
>Reporter: David Radley
>Assignee: David Radley
>  Labels: VirtualDataConnector
> Attachments: ATLAS1698-1.patch, ATLAS1698.patch, Atlas Glossary OMAS 
> API proposal v1.0 .pdf, Atlas Glossary OMAS API proposal v1.1.pdf, Atlas 
> Glossary OMAS API proposal v1.2.pdf, Subject Area OMAS API proposal v1.3.pdf, 
> Subject Area OMAS API proposal v1.4.pdf, apidocs-1.zip, apidocs.zip
>
>
> The Subject Area OMAS provides a specialized API for glossary applications to 
> retrieve and store their glossary metadata and link assets of different types 
> to these glossary entries.
> The Subject Area OMAS makes heavy use of the Area 3 open metadata model.  See 
> https://issues.apache.org/jira/browse/ATLAS-1840



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-1698) Create Subject Area OMAS API

[David Radley (JIRA)]

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

David Radley updated ATLAS-1698:

Attachment: apidocs-1.zip

> Create Subject Area OMAS API
> 
>
> Key: ATLAS-1698
> URL: https://issues.apache.org/jira/browse/ATLAS-1698
> Project: Atlas
>  Issue Type: Sub-task
>Reporter: David Radley
>Assignee: David Radley
>  Labels: VirtualDataConnector
> Attachments: ATLAS1698-1.patch, ATLAS1698.patch, Atlas Glossary OMAS 
> API proposal v1.0 .pdf, Atlas Glossary OMAS API proposal v1.1.pdf, Atlas 
> Glossary OMAS API proposal v1.2.pdf, Subject Area OMAS API proposal v1.3.pdf, 
> apidocs-1.zip, apidocs.zip
>
>
> The Subject Area OMAS provides a specialized API for glossary applications to 
> retrieve and store their glossary metadata and link assets of different types 
> to these glossary entries.
> The Subject Area OMAS makes heavy use of the Area 3 open metadata model.  See 
> https://issues.apache.org/jira/browse/ATLAS-1840



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-1698) Create Subject Area OMAS API

[David Radley (JIRA)]

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

David Radley updated ATLAS-1698:

Attachment: ATLAS1698-1.patch

> Create Subject Area OMAS API
> 
>
> Key: ATLAS-1698
> URL: https://issues.apache.org/jira/browse/ATLAS-1698
> Project: Atlas
>  Issue Type: Sub-task
>Reporter: David Radley
>Assignee: David Radley
>  Labels: VirtualDataConnector
> Attachments: ATLAS1698-1.patch, ATLAS1698.patch, Atlas Glossary OMAS 
> API proposal v1.0 .pdf, Atlas Glossary OMAS API proposal v1.1.pdf, Atlas 
> Glossary OMAS API proposal v1.2.pdf, Subject Area OMAS API proposal v1.3.pdf, 
> apidocs.zip
>
>
> The Subject Area OMAS provides a specialized API for glossary applications to 
> retrieve and store their glossary metadata and link assets of different types 
> to these glossary entries.
> The Subject Area OMAS makes heavy use of the Area 3 open metadata model.  See 
> https://issues.apache.org/jira/browse/ATLAS-1840



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ATLAS-1757) Proposal to update graph DB

[David Radley (JIRA)]

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

David Radley commented on ATLAS-1757:
-

[~hulbs] The equivalent to the RDB grant is all done through Ranger - which 
gives us great separation of responsibility and flexibility.  I have no reason 
to think that Apache Ranger mechanism is not strong enough for the use cases we 
have looked at.   

If the data really needs to be separate - and does not need to be joined, then 
it might make sense to have them in separate data lakes - i.e. separate 
Atlas's. 

> Proposal to update graph DB
> ---
>
> Key: ATLAS-1757
> URL: https://issues.apache.org/jira/browse/ATLAS-1757
> Project: Atlas
>  Issue Type: Improvement
>  Components:  atlas-core
>Affects Versions: trunk
>Reporter: Graham Wallis
> Attachments: ATLAS-1757 Proposal to change graph database.pdf, 
> ATLAS-1757-v1.patch, ATLAS-1757-v2.patch
>
>
> Given the formation of the JanusGraph open source project (under the Linux 
> Foundation) to continue the development and support of the Titan DB, should 
> we aim to deprecate Titan and move over to JanusGraph?
> If we did this, we could keep the graph abstraction layer and use it to 
> support Titan 0, Titan 1 and JanusGraph.
> Are there other graph databases that we should consider?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-1839) Area 3 of the open metadata model - including the Glossary

[David Radley (JIRA)]

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

David Radley updated ATLAS-1839:

Attachment: ATLAS1839-3.patch

> Area 3 of the open metadata model - including the Glossary
> --
>
> Key: ATLAS-1839
> URL: https://issues.apache.org/jira/browse/ATLAS-1839
> Project: Atlas
>  Issue Type: Task
>  Components:  atlas-core
>Affects Versions: 1.0.0
>Reporter: Mandy Chessell
>Assignee: David Radley
>  Labels: OpenMetadata, VirtualDataConnector
> Attachments: ATLAS1839-1.patch, ATLAS1839-2.patch, ATLAS1839-3.patch, 
> ATLAS1839.patch
>
>
> This task delivers the JSON files for the new models that describe types for 
> Area 3 in the open metadata model. This area covers the glossary.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-2200) Area 0 keyPattern attribute does not refer to the KeyPattern enum

[David Radley (JIRA)]

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

David Radley updated ATLAS-2200:

Attachment: ATLAS2200.patch

> Area 0 keyPattern attribute does not refer to the KeyPattern enum
> -
>
> Key: ATLAS-2200
> URL: https://issues.apache.org/jira/browse/ATLAS-2200
> Project: Atlas
>  Issue Type: Bug
>Reporter: David Radley
>Assignee: David Radley
> Attachments: ATLAS2200.patch
>
>
> Area 0 model file 
> addons/models/-Area0/0017-ExternalIdentifiers_model.json keyPattern 
> attribute has type string. This is incorrect it should be type KeyPattern.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (ATLAS-2200) Area 0 keyPattern attribute does not refer to the KeyPattern enum

[David Radley (JIRA)]

David Radley created ATLAS-2200:
---

 Summary: Area 0 keyPattern attribute does not refer to the 
KeyPattern enum
 Key: ATLAS-2200
 URL: https://issues.apache.org/jira/browse/ATLAS-2200
 Project: Atlas
  Issue Type: Bug
Reporter: David Radley
Assignee: David Radley


Area 0 model file addons/models/-Area0/0017-ExternalIdentifiers_model.json 
keyPattern attribute has type string. This is incorrect it should be type 
KeyPattern.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-1839) Area 3 of the open metadata model - including the Glossary

[David Radley (JIRA)]

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

David Radley updated ATLAS-1839:

Attachment: ATLAS1839-1.patch

> Area 3 of the open metadata model - including the Glossary
> --
>
> Key: ATLAS-1839
> URL: https://issues.apache.org/jira/browse/ATLAS-1839
> Project: Atlas
>  Issue Type: Task
>  Components:  atlas-core
>Affects Versions: 1.0.0
>Reporter: Mandy Chessell
>Assignee: David Radley
>  Labels: OpenMetadata, VirtualDataConnector
> Attachments: ATLAS1839-1.patch, ATLAS1839.patch
>
>
> This task delivers the JSON files for the new models that describe types for 
> Area 3 in the open metadata model. This area covers the glossary.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-1839) Area 3 of the open metadata model - including the Glossary

[David Radley (JIRA)]

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

David Radley updated ATLAS-1839:

Attachment: ATLAS1839.patch

https://reviews.apache.org/r/62846/

> Area 3 of the open metadata model - including the Glossary
> --
>
> Key: ATLAS-1839
> URL: https://issues.apache.org/jira/browse/ATLAS-1839
> Project: Atlas
>  Issue Type: Task
>  Components:  atlas-core
>Affects Versions: 1.0.0
>Reporter: Mandy Chessell
>Assignee: David Radley
>  Labels: OpenMetadata, VirtualDataConnector
> Attachments: ATLAS1839.patch
>
>
> This task delivers the JSON files for the new models that describe types for 
> Area 3 in the open metadata model. This area covers the glossary.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-1839) Area 3 of the open metadata model - including the Glossary

[David Radley (JIRA)]

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

David Radley updated ATLAS-1839:

Attachment: (was: 0210Glossary.json)

> Area 3 of the open metadata model - including the Glossary
> --
>
> Key: ATLAS-1839
> URL: https://issues.apache.org/jira/browse/ATLAS-1839
> Project: Atlas
>  Issue Type: Task
>  Components:  atlas-core
>Affects Versions: 1.0.0
>Reporter: Mandy Chessell
>Assignee: David Radley
>  Labels: OpenMetadata, VirtualDataConnector
>
> This task delivers the JSON files for the new models that describe types for 
> Area 3 in the open metadata model. This area covers the glossary.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-1839) Area 3 of the open metadata model - including the Glossary

[David Radley (JIRA)]

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

David Radley updated ATLAS-1839:

Attachment: (was: 0260Contexts.json)

> Area 3 of the open metadata model - including the Glossary
> --
>
> Key: ATLAS-1839
> URL: https://issues.apache.org/jira/browse/ATLAS-1839
> Project: Atlas
>  Issue Type: Task
>  Components:  atlas-core
>Affects Versions: 1.0.0
>Reporter: Mandy Chessell
>Assignee: David Radley
>  Labels: OpenMetadata, VirtualDataConnector
>
> This task delivers the JSON files for the new models that describe types for 
> Area 3 in the open metadata model. This area covers the glossary.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-1839) Area 3 of the open metadata model - including the Glossary

[David Radley (JIRA)]

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

David Radley updated ATLAS-1839:

Attachment: (was: 0230Terms.json)

> Area 3 of the open metadata model - including the Glossary
> --
>
> Key: ATLAS-1839
> URL: https://issues.apache.org/jira/browse/ATLAS-1839
> Project: Atlas
>  Issue Type: Task
>  Components:  atlas-core
>Affects Versions: 1.0.0
>Reporter: Mandy Chessell
>Assignee: David Radley
>  Labels: OpenMetadata, VirtualDataConnector
>
> This task delivers the JSON files for the new models that describe types for 
> Area 3 in the open metadata model. This area covers the glossary.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-1839) Area 3 of the open metadata model - including the Glossary

[David Radley (JIRA)]

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

David Radley updated ATLAS-1839:

Attachment: (was: 0270SemanticAssignment.json)

> Area 3 of the open metadata model - including the Glossary
> --
>
> Key: ATLAS-1839
> URL: https://issues.apache.org/jira/browse/ATLAS-1839
> Project: Atlas
>  Issue Type: Task
>  Components:  atlas-core
>Affects Versions: 1.0.0
>Reporter: Mandy Chessell
>Assignee: David Radley
>  Labels: OpenMetadata, VirtualDataConnector
>
> This task delivers the JSON files for the new models that describe types for 
> Area 3 in the open metadata model. This area covers the glossary.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-1839) Area 3 of the open metadata model - including the Glossary

[David Radley (JIRA)]

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

David Radley updated ATLAS-1839:

Attachment: (was: 0250RelatedTerms.json)

> Area 3 of the open metadata model - including the Glossary
> --
>
> Key: ATLAS-1839
> URL: https://issues.apache.org/jira/browse/ATLAS-1839
> Project: Atlas
>  Issue Type: Task
>  Components:  atlas-core
>Affects Versions: 1.0.0
>Reporter: Mandy Chessell
>Assignee: David Radley
>  Labels: OpenMetadata, VirtualDataConnector
>
> This task delivers the JSON files for the new models that describe types for 
> Area 3 in the open metadata model. This area covers the glossary.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-1839) Area 3 of the open metadata model - including the Glossary

[David Radley (JIRA)]

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

David Radley updated ATLAS-1839:

Attachment: (was: 0280SpineObjects.json)

> Area 3 of the open metadata model - including the Glossary
> --
>
> Key: ATLAS-1839
> URL: https://issues.apache.org/jira/browse/ATLAS-1839
> Project: Atlas
>  Issue Type: Task
>  Components:  atlas-core
>Affects Versions: 1.0.0
>Reporter: Mandy Chessell
>Assignee: David Radley
>  Labels: OpenMetadata, VirtualDataConnector
>
> This task delivers the JSON files for the new models that describe types for 
> Area 3 in the open metadata model. This area covers the glossary.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-1839) Area 3 of the open metadata model - including the Glossary

[David Radley (JIRA)]

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

David Radley updated ATLAS-1839:

Attachment: (was: 0240Dictionary.json)

> Area 3 of the open metadata model - including the Glossary
> --
>
> Key: ATLAS-1839
> URL: https://issues.apache.org/jira/browse/ATLAS-1839
> Project: Atlas
>  Issue Type: Task
>  Components:  atlas-core
>Affects Versions: 1.0.0
>Reporter: Mandy Chessell
>Assignee: David Radley
>  Labels: OpenMetadata, VirtualDataConnector
>
> This task delivers the JSON files for the new models that describe types for 
> Area 3 in the open metadata model. This area covers the glossary.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-1839) Area 3 of the open metadata model - including the Glossary

[David Radley (JIRA)]

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

David Radley updated ATLAS-1839:

Attachment: (was: 0220CategoryHierarchy.json)

> Area 3 of the open metadata model - including the Glossary
> --
>
> Key: ATLAS-1839
> URL: https://issues.apache.org/jira/browse/ATLAS-1839
> Project: Atlas
>  Issue Type: Task
>  Components:  atlas-core
>Affects Versions: 1.0.0
>Reporter: Mandy Chessell
>Assignee: David Radley
>  Labels: OpenMetadata, VirtualDataConnector
>
> This task delivers the JSON files for the new models that describe types for 
> Area 3 in the open metadata model. This area covers the glossary.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-1836) Area 0 of the open metadata model

[David Radley (JIRA)]

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

David Radley updated ATLAS-1836:

Attachment: ATLAS1836-5.patch

> Area 0 of the open metadata model
> -
>
> Key: ATLAS-1836
> URL: https://issues.apache.org/jira/browse/ATLAS-1836
> Project: Atlas
>  Issue Type: Task
>  Components:  atlas-core
>Reporter: Mandy Chessell
>Assignee: David Radley
>  Labels: OpenMetadata, VirtualDataConnector
> Attachments: ATLAS-1836-1.patch, ATLAS-1836.patch, ATLAS1836-2.patch, 
> ATLAS1836-3.patch, ATLAS1836-4.patch, ATLAS1836-5.patch
>
>
> This task delivers the JSON files for the new models that describe types for 
> Area 0 in the open metadata model.  This area covers base types.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-1698) Create Subject Area OMAS API

[David Radley (JIRA)]

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

David Radley updated ATLAS-1698:

Description: 
The Subject Area OMAS provides a specialized API for glossary applications to 
retrieve and store their glossary metadata and link assets of different types 
to these glossary entries.

The Subject Matter OMAS makes heavy use of the Area 3 open metadata model.  See 
https://issues.apache.org/jira/browse/ATLAS-1840


  was:
The Subject Matter OMAS provides a specialized API for glossary applications to 
retrieve and store their glossary metadata and link assets of different types 
to these glossary entries.

The Subject Matter OMAS makes heavy use of the Area 3 open metadata model.  See 
https://issues.apache.org/jira/browse/ATLAS-1840


Summary: Create Subject Area OMAS API  (was: Create Subject Matter OMAS 
API)

> Create Subject Area OMAS API
> 
>
> Key: ATLAS-1698
> URL: https://issues.apache.org/jira/browse/ATLAS-1698
> Project: Atlas
>  Issue Type: Sub-task
>Reporter: David Radley
>Assignee: David Radley
>  Labels: VirtualDataConnector
> Attachments: apidocs.zip, ATLAS1698.patch, Atlas Glossary OMAS API 
> proposal v1.0 .pdf, Atlas Glossary OMAS API proposal v1.1.pdf, Atlas Glossary 
> OMAS API proposal v1.2.pdf, Subject Area OMAS API proposal v1.3.pdf
>
>
> The Subject Area OMAS provides a specialized API for glossary applications to 
> retrieve and store their glossary metadata and link assets of different types 
> to these glossary entries.
> The Subject Matter OMAS makes heavy use of the Area 3 open metadata model.  
> See https://issues.apache.org/jira/browse/ATLAS-1840



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-1698) Create Subject Area OMAS API

[David Radley (JIRA)]

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

David Radley updated ATLAS-1698:

Description: 
The Subject Area OMAS provides a specialized API for glossary applications to 
retrieve and store their glossary metadata and link assets of different types 
to these glossary entries.

The Subject Area OMAS makes heavy use of the Area 3 open metadata model.  See 
https://issues.apache.org/jira/browse/ATLAS-1840


  was:
The Subject Area OMAS provides a specialized API for glossary applications to 
retrieve and store their glossary metadata and link assets of different types 
to these glossary entries.

The Subject Matter OMAS makes heavy use of the Area 3 open metadata model.  See 
https://issues.apache.org/jira/browse/ATLAS-1840



> Create Subject Area OMAS API
> 
>
> Key: ATLAS-1698
> URL: https://issues.apache.org/jira/browse/ATLAS-1698
> Project: Atlas
>  Issue Type: Sub-task
>Reporter: David Radley
>Assignee: David Radley
>  Labels: VirtualDataConnector
> Attachments: apidocs.zip, ATLAS1698.patch, Atlas Glossary OMAS API 
> proposal v1.0 .pdf, Atlas Glossary OMAS API proposal v1.1.pdf, Atlas Glossary 
> OMAS API proposal v1.2.pdf, Subject Area OMAS API proposal v1.3.pdf
>
>
> The Subject Area OMAS provides a specialized API for glossary applications to 
> retrieve and store their glossary metadata and link assets of different types 
> to these glossary entries.
> The Subject Area OMAS makes heavy use of the Area 3 open metadata model.  See 
> https://issues.apache.org/jira/browse/ATLAS-1840



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-1698) Create Subject Area OMAS API

[David Radley (JIRA)]

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

David Radley updated ATLAS-1698:

Attachment: (was: Subject Matter OMAS API proposal v1.3.pdf)

> Create Subject Area OMAS API
> 
>
> Key: ATLAS-1698
> URL: https://issues.apache.org/jira/browse/ATLAS-1698
> Project: Atlas
>  Issue Type: Sub-task
>Reporter: David Radley
>Assignee: David Radley
>  Labels: VirtualDataConnector
> Attachments: apidocs.zip, ATLAS1698.patch, Atlas Glossary OMAS API 
> proposal v1.0 .pdf, Atlas Glossary OMAS API proposal v1.1.pdf, Atlas Glossary 
> OMAS API proposal v1.2.pdf, Subject Area OMAS API proposal v1.3.pdf
>
>
> The Subject Area OMAS provides a specialized API for glossary applications to 
> retrieve and store their glossary metadata and link assets of different types 
> to these glossary entries.
> The Subject Matter OMAS makes heavy use of the Area 3 open metadata model.  
> See https://issues.apache.org/jira/browse/ATLAS-1840



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ATLAS-1698) Create Subject Area OMAS API

[David Radley (JIRA)]

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

David Radley updated ATLAS-1698:

Attachment: Subject Area OMAS API proposal v1.3.pdf

> Create Subject Area OMAS API
> 
>
> Key: ATLAS-1698
> URL: https://issues.apache.org/jira/browse/ATLAS-1698
> Project: Atlas
>  Issue Type: Sub-task
>Reporter: David Radley
>Assignee: David Radley
>  Labels: VirtualDataConnector
> Attachments: apidocs.zip, ATLAS1698.patch, Atlas Glossary OMAS API 
> proposal v1.0 .pdf, Atlas Glossary OMAS API proposal v1.1.pdf, Atlas Glossary 
> OMAS API proposal v1.2.pdf, Subject Area OMAS API proposal v1.3.pdf
>
>
> The Subject Area OMAS provides a specialized API for glossary applications to 
> retrieve and store their glossary metadata and link assets of different types 
> to these glossary entries.
> The Subject Area OMAS makes heavy use of the Area 3 open metadata model.  See 
> https://issues.apache.org/jira/browse/ATLAS-1840



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)