atlas-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Markwat (JIRA)" <j...@apache.org>
Subject [jira] [Created] (ATLAS-1161) Tags should be bound to an object's name and remain bound to all incarnations of that name
Date Fri, 09 Sep 2016 19:16:21 GMT
Dan Markwat created ATLAS-1161:
----------------------------------

             Summary: 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)

Mime
View raw message