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

Anurag Parvatikar commented on HDDS-17374:
------------------------------------------

The behaviour of allocateBlock is to allocate a block based on the args passed 
to it. We would be modifying the core behaviour of allocateBlock here, which is 
not intended. Hence, the following scenarios must be documented for the feature 
- If the bucket policy changes before a subsequent allocateBlock made from an 
older client, then some blocks of the key will not respect the StoragePolicy of 
the key.

cc: [~deveshsingh] .

> Handle old clients not passing StoragePolicy in allocateBlock
> -------------------------------------------------------------
>
>                 Key: HDDS-17374
>                 URL: https://issues.apache.org/jira/browse/HDDS-17374
>             Project: Apache Ozone
>          Issue Type: Sub-task
>            Reporter: Anurag Parvatikar
>            Assignee: Anurag Parvatikar
>            Priority: Major
>              Labels: pull-request-available
>
> Handle old clients not passing StoragePolicy to OM in AllocateBlock: With an 
> upgraded cluster containing all OMs supporting storagePolicy, an older client 
> will not send the StoragePolicy field in any request made to the OM. This is 
> of consequence to the allocateBlock as it allocates block based on the 
> StoragePolicy sent by the client. If the client doesn't send a storage 
> policy, it uses the bucket policy and falls back to the default. 
> If the Key is created with the Bucket policy and before the subsequent 
> allocateBlock call, the bucket policy changes, then allocateBlock would not 
> stay true to the Key's StoragePolicy.
>  
> This ticket is to handle such a scenario.



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to