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

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

{quote}
In the current Atlas world, if I create TableA again, Tag1 and Tag2 need to be 
re-applied to TableA
{quote}
I think it makes sense to not carry over the tags from old entity. The new 
entity, even though has the same name as old entity, might have been derived in 
a different way and mean something else. Even I think rule based classification 
would be a better fit here.

{quote}
By effectively deleting the binding of Tag1 and Tag2 to the name TableA 
whenever TableA is deleted, Atlas ceases to be a book of record for tags 
associated with TableA, as those tags would need to be applied again.
{quote}
By default, entity deletes are soft deletes. So, when TableA is deleted, its 
just marked as deleted and all the tag associations still remain and search 
retrieves the deleted entities as well. When TableA is re-created, atlas 
creates another entity(with new guid) and with no tags. So, both the old and 
new entity exists and its possible to look at both of them for audit. 
Additionally, each entity has audit trail that records tag associations, that 
can be viewed for both active and deleted entities

> Tags should be bound to an object's name and remain bound to all incarnations 
> of that name
> ------------------------------------------------------------------------------------------
>
>                 Key: ATLAS-1161
>                 URL: https://issues.apache.org/jira/browse/ATLAS-1161
>             Project: Atlas
>          Issue Type: Improvement
>    Affects Versions: trunk, 0.7-incubating
>            Reporter: Dan Markwat
>
> As a user I would like tags I ascribe to an object in Atlas carry to the next 
> incarnation of that object.  In effect, tags would be ascribed to a 
> fully-qualified object name and all incarnations of that name would have the 
> tags apply to it.  (Not unlike Ranger and the way it applies policies to 
> objects).
> Example: I create a Hive table, TableA.  I tag TableA with tags, Tag1 and 
> Tag2.  I drop TableA.
> In the current Atlas world, if I create TableA again, Tag1 and Tag2 need to 
> be re-applied to TableA.  In the ideal governance/security world, if I 
> re-create TableA I should not have to re-tag it with Tag1 and Tag2; instead, 
> I should be required to *untag* TableA if I desire TableA to be clean and 
> untagged.  This effectively functions like a light switch: user turns on 
> light, just because the bulb is swapped out doesn't mean the switch turned 
> off - the user must explicitly turn the switch off, just as they did to turn 
> it on.  Think also about Ranger: just because I deleted an object doesn't 
> mean that policy goes away.
> By effectively deleting the binding of Tag1 and Tag2 to the name TableA 
> whenever TableA is deleted, Atlas ceases to be a book of record for tags 
> associated with TableA, as those tags would need to be applied again.  This 
> is bad in a world where creating/dropping objects and tagging objects are 
> part of 2 independent and asynchronous processes - one carried out by an 
> engineer, the other carried out by a governance/security administrator.  The 
> issue is compounded by the fact that tags can have security policies 
> associated with them in Ranger; and any object missing its tag at re-creation 
> of that object now is missing security policies previously attached to it.
> This is an especially annoying issue for organizations that have large 
> ingestion pipelines where tables are sometimes deleted or modified in ways 
> not easily accomplished through updating table metadata.  Not to mention, 
> (probably a new feature: ) easily-accessible records of what was tagged with 
> what - even if the object has been dropped or deleted - is especially 
> important for organizations that require auditing or have security controls 
> based on tag-based policies.



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

Reply via email to