[
https://issues.apache.org/jira/browse/HDDS-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Chitlangia updated HDDS-2161:
------------------------------------
Description:
Currently, OM Metadata deletedTable stores <Key Name, OMKeyInfo>
When a user deletes a Key, <key name, omKeyInfo> is moved to deletedTable.
If a user creates and deletes key with exact same name in quick succession
repeatedly, then old <key name, omKeyInfo> can get overwritten and we may be
left with dangling blocks.
To address this, currently we append delete timestamp to keyname and preserve
the multiple delete attempts for same key name.
However, for GDPR compliance we need a way to check if a key is deleted from
deletedTable and thus given the above explanation, we may not get accurate
information and it must also confuse the users.
This Jira aims to:
# Create new structure RepeatedKeyInfo which allows us to group multiple
KeyInfo which can be saved to deletedTable corresponding to a keyname as
<KeyName, RepeatedKeyInfo>
# Due to this, before we move a key to deletedTable, we need to check if key
with same name exists. If yes, then fetch the existing instance and add the
latest key to the list, store it back to deletedTable, else create a new
instance and save to table
was:
Currently, OM Metadata deletedTable stores <Key Name, OMKeyInfo>
When a user deletes a Key, <key name, omKeyInfo> is moved to deletedTable.
If a user creates and deletes key with exact same name in quick succession
repeatedly, then old <key name, omKeyInfo> can get overwritten and we may be
left with dangling blocks.
To address this, currently we append delete timestamp to keyname and preserve
the multiple delete attempts for same key name.
However, for GDPR compliance we need a way to check if a key is deleted from
deletedTable and thus given the above explanation, we may not get accurate
information and it must also confuse the users.
This Jira aims to:
# Create new structure RepeatedKeyInfo which allows us to group multiple
KeyInfo which can be saved to deletedTable corresponding to a keyname as
<KeyName, RepeatedKeyInfo>
# Due to this, before we move a key to deletedTable, we need to check if key
with same name exists. If yes, then fetch the existing instance and add the
latest key to the list, store it back to deletedTable.
> Create RepeatedKeyInfo structure to be saved in deletedTable
> ------------------------------------------------------------
>
> Key: HDDS-2161
> URL: https://issues.apache.org/jira/browse/HDDS-2161
> Project: Hadoop Distributed Data Store
> Issue Type: Sub-task
> Reporter: Dinesh Chitlangia
> Assignee: Dinesh Chitlangia
> Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Currently, OM Metadata deletedTable stores <Key Name, OMKeyInfo>
> When a user deletes a Key, <key name, omKeyInfo> is moved to deletedTable.
> If a user creates and deletes key with exact same name in quick succession
> repeatedly, then old <key name, omKeyInfo> can get overwritten and we may be
> left with dangling blocks.
> To address this, currently we append delete timestamp to keyname and preserve
> the multiple delete attempts for same key name.
> However, for GDPR compliance we need a way to check if a key is deleted from
> deletedTable and thus given the above explanation, we may not get accurate
> information and it must also confuse the users.
>
> This Jira aims to:
> # Create new structure RepeatedKeyInfo which allows us to group multiple
> KeyInfo which can be saved to deletedTable corresponding to a keyname as
> <KeyName, RepeatedKeyInfo>
> # Due to this, before we move a key to deletedTable, we need to check if key
> with same name exists. If yes, then fetch the existing instance and add the
> latest key to the list, store it back to deletedTable, else create a new
> instance and save to table
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
