[jira] [Created] (HADOOP-16730) ABFS: Support for Shared Access Signatures (SAS)
Thomas Marqardt created HADOOP-16730: Summary: ABFS: Support for Shared Access Signatures (SAS) Key: HADOOP-16730 URL: https://issues.apache.org/jira/browse/HADOOP-16730 Project: Hadoop Common Issue Type: New Feature Components: fs/azure Affects Versions: 3.2.1 Reporter: Thomas Marqardt Assignee: Sneha Vijayarajan ABFS supports OAuth and Shared Key but currently lacks support for [Shared Access Signatures (SAS)|[https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview]]. SAS is a great way to constrain access to a low-privilege ABFS client. The ABFS client does not need to possess persistent credentials for accessing storage but instead can request temporary, constrained access tokens from a trusted endpoint. This endpoint can authenticate the caller, make an authorization decision and return a constrained SAS token. The token may have an expiration, it may be scoped to a specific file or directory, and it may grant an action or set of actions such as read, write, list, or delete. Azure Storage also has a new identity based SAS scheme in preview named Delegation SAS. These new Delegation SAS have these advantages over Service SAS: 1) Delegation SAS provide authentication as well as authorization. The user identity associated with each request will appear in the logs when logging is enabled for the account. 2) Instead of using storage account keys to sign tokens, Delegation SAS relies on keys assigned to each user. These keys are called user delegation keys. If a storage account key is leaked, an attacker would have full access to the storage account. If a user delegation key is leaked, an attacker would only have access to resources that user has access to within the Blob service–for example, the user might only have read access to a specific container. This feature will add support for the ABFS driver to authenticate against a trusted endpoint. The endpoint will return a SAS which the ABFS driver will use to access Azure storage. The SAS may be a container or directory SAS to be used for all subsequent operations, and thus cached for the lifetime of the filesystem. Or it may be a SAS to be used for the current filesystem operation, in this case, the ABFS driver will request a SAS for each operation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
[jira] [Resolved] (HADOOP-16825) ITestAzureBlobFileSystemCheckAccess failing
[ https://issues.apache.org/jira/browse/HADOOP-16825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Marqardt resolved HADOOP-16825. -- Fix Version/s: 3.3.0 Resolution: Fixed commit 5944d28130925fe1452f545e96b5e44f064bc69e Author: bilaharith <52483117+bilahar...@users.noreply.github.com> Date: Thu Feb 6 18:48:00 2020 + HADOOP-16825: ITestAzureBlobFileSystemCheckAccess failing. Contributed by Bilahari T H. > ITestAzureBlobFileSystemCheckAccess failing > --- > > Key: HADOOP-16825 > URL: https://issues.apache.org/jira/browse/HADOOP-16825 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/azure, test >Affects Versions: 3.3.0 >Reporter: Steve Loughran >Assignee: Bilahari T H >Priority: Major > Fix For: 3.3.0 > > > Tests added in HADOOP-16455 are failing. > java.lang.IllegalArgumentException: The value of property > fs.azure.account.oauth2.client.id must not be null > Looks to me like there are new configuration options which are undocumented > # these need documentation in testing markdown file > # tests MUST downgrade to skip if not set -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
[jira] [Resolved] (HADOOP-16845) ITestAbfsClient.testContinuationTokenHavingEqualSign failing
[ https://issues.apache.org/jira/browse/HADOOP-16845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Marqardt resolved HADOOP-16845. -- Fix Version/s: 3.3.0 Resolution: Fixed commit 55f2421580678a6793c8cb6ad10fee3f4ec833aa Author: Sneha Vijayarajan Date: Thu Feb 6 18:41:06 2020 + HADOOP-16845: Disable ITestAbfsClient.testContinuationTokenHavingEqualSign due to ADLS Gen2 service bug. Contributed by Sneha Vijayarajan. > ITestAbfsClient.testContinuationTokenHavingEqualSign failing > > > Key: HADOOP-16845 > URL: https://issues.apache.org/jira/browse/HADOOP-16845 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/azure, test >Affects Versions: 3.3.0 >Reporter: Sneha Vijayarajan >Assignee: Sneha Vijayarajan >Priority: Major > Fix For: 3.3.0 > > > Testcase testContinuationTokenHavingEqualSign is failing as request that was > expected to fail is passing. > There is change in the queryparam validation in ContinuationToken at server > end wihch has resulted in this behaviour. > Server request trace: > 2020-02-05 16:59:17,001 DEBUG [JUnit-testContinuationTokenHavingEqualSign]: > services.AbfsClient (AbfsRestOperation.java:executeHttpOperation(263)) - > HttpRequest: > 200,,cid=87c3ebea-def7-4fdd-a21a-a56c63a59387,rid=0931c565-201f-004c-1317-dcdd9000,sent=0,recv=0,GET,[https://snvijayaabfsns.dfs.core.windows.net/abfs-testcontainer-85bb9523-fccd-45f3-ae6d-37622d8231e5?upn=false&resource=filesystem&maxResults=500&directory=/&continuation=%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D&timeout=90&recursive=true] > > Disabling the test until the server fix is in and deployed on all regions. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
[jira] [Created] (HADOOP-16916) ABFS: Delegation SAS generator for integration with Ranger
Thomas Marqardt created HADOOP-16916: Summary: ABFS: Delegation SAS generator for integration with Ranger Key: HADOOP-16916 URL: https://issues.apache.org/jira/browse/HADOOP-16916 Project: Hadoop Common Issue Type: New Feature Components: fs/azure Affects Versions: 3.2.1 Reporter: Thomas Marqardt HADOOP-16730 added support for Shared Access Signatures (SAS). Azure Data Lake Storage Gen2 supports a new SAS type known as User Delegation SAS. This Jira tracks an update to the ABFS driver that will include a Delegation SAS generator and tests to validate that this SAS type is working correctly with the driver. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
[jira] [Created] (HADOOP-17076) ABFS: Delegation SAS Generator Updates
Thomas Marqardt created HADOOP-17076: Summary: ABFS: Delegation SAS Generator Updates Key: HADOOP-17076 URL: https://issues.apache.org/jira/browse/HADOOP-17076 Project: Hadoop Common Issue Type: New Feature Components: fs/azure Affects Versions: 3.2.1 Reporter: Thomas Marqardt Assignee: Thomas Marqardt # The authentication version in the service has been updated from Dec19 to Feb20, so need to update the client. # Add support and test cases for getXattr and setXAttr. # Update DelegationSASGenerator and related to use Duration instead of int for time periods. # Cleanup DelegationSASGenerator switch/case statement that maps operations to permissions. # Cleanup SASGenerator classes to use String.equals instead of ==. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
[jira] [Resolved] (HADOOP-17076) ABFS: Delegation SAS Generator Updates
[ https://issues.apache.org/jira/browse/HADOOP-17076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Marqardt resolved HADOOP-17076. -- Fix Version/s: 3.3.0 Release Note: Azure Blob File System (ABFS) SAS Generator Update Resolution: Fixed commit caf3995ac2bbc3241896babb9a607272462f70ca Author: Thomas Marquardt Date: Wed Jun 17 23:12:22 2020 + HADOOP-17076: ABFS: Delegation SAS Generator Updates Contributed by Thomas Marquardt. > ABFS: Delegation SAS Generator Updates > -- > > Key: HADOOP-17076 > URL: https://issues.apache.org/jira/browse/HADOOP-17076 > Project: Hadoop Common > Issue Type: New Feature > Components: fs/azure >Affects Versions: 3.2.1 >Reporter: Thomas Marqardt >Assignee: Thomas Marqardt >Priority: Minor > Fix For: 3.3.0 > > > # The authentication version in the service has been updated from Dec19 to > Feb20, so need to update the client. > # Add support and test cases for getXattr and setXAttr. > # Update DelegationSASGenerator and related to use Duration instead of int > for time periods. > # Cleanup DelegationSASGenerator switch/case statement that maps operations > to permissions. > # Cleanup SASGenerator classes to use String.equals instead of ==. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
[jira] [Reopened] (HADOOP-17054) ABFS: Fix idempotency test failures when SharedKey is set as AuthType
[ https://issues.apache.org/jira/browse/HADOOP-17054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Marqardt reopened HADOOP-17054: -- We should revisit this and try to find a better solution for rename. App developers expect our Rename to be atomic. The service implementation is atomic, but we have this client-side idempotency issue. Your fix relies on time and assumes that if the destination was recently updated while we are executing a retry policy, that we succeeded. This may not be the case. For example, app developers may rely on rename (with overwrite = false) of a file to synchronize or act like a distributed lock, so who ever renames successfully acquires the lock. With your fix, multiple callers could acquire this lock at the same time. Instead, I think we could allow the client to provide a UUID for the rename operation and persist this UUID in the metadata of the destination blob upon successful completion of a rename, then if we get into this idempotency issue and the client gets a 404 source does not exist, we can check the destination blob's metadata to see if the UUID is a match. > ABFS: Fix idempotency test failures when SharedKey is set as AuthType > - > > Key: HADOOP-17054 > URL: https://issues.apache.org/jira/browse/HADOOP-17054 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/azure >Affects Versions: 3.2.1 >Reporter: Sneha Vijayarajan >Assignee: Sneha Vijayarajan >Priority: Major > Fix For: 3.4.0 > > > Idempotency related tests added as part of > https://issues.apache.org/jira/browse/HADOOP-17015 > create a test AbfsClient instance. This mock instance wrongly accepts valid > sharedKey and oauth token provider instance. This leads to test failures with > exceptions: > [ERROR] > testRenameRetryFailureAsHTTP404(org.apache.hadoop.fs.azurebfs.ITestAzureBlobFileSystemRename) > Time elapsed: 9.133 s <<< ERROR! > Invalid auth type: SharedKey is being used, expecting OAuth > at > org.apache.hadoop.fs.azurebfs.AbfsConfiguration.getTokenProvider(AbfsConfiguration.java:643) > This Jira is to fix these tests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
[jira] [Resolved] (HADOOP-17054) ABFS: Fix idempotency test failures when SharedKey is set as AuthType
[ https://issues.apache.org/jira/browse/HADOOP-17054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Marqardt resolved HADOOP-17054. -- Resolution: Fixed Accidentally reactivated HADOOP-17015 but meant to reactivate HADOOP-17054. Please ignore previous comment. > ABFS: Fix idempotency test failures when SharedKey is set as AuthType > - > > Key: HADOOP-17054 > URL: https://issues.apache.org/jira/browse/HADOOP-17054 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/azure >Affects Versions: 3.2.1 >Reporter: Sneha Vijayarajan >Assignee: Sneha Vijayarajan >Priority: Major > Fix For: 3.4.0 > > > Idempotency related tests added as part of > https://issues.apache.org/jira/browse/HADOOP-17015 > create a test AbfsClient instance. This mock instance wrongly accepts valid > sharedKey and oauth token provider instance. This leads to test failures with > exceptions: > [ERROR] > testRenameRetryFailureAsHTTP404(org.apache.hadoop.fs.azurebfs.ITestAzureBlobFileSystemRename) > Time elapsed: 9.133 s <<< ERROR! > Invalid auth type: SharedKey is being used, expecting OAuth > at > org.apache.hadoop.fs.azurebfs.AbfsConfiguration.getTokenProvider(AbfsConfiguration.java:643) > This Jira is to fix these tests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
[jira] [Reopened] (HADOOP-17015) ABFS: Make PUT and POST operations idempotent
[ https://issues.apache.org/jira/browse/HADOOP-17015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Marqardt reopened HADOOP-17015: -- We should revisit PR 2021 and try to find a better solution for rename. Users expect Rename to be atomic. The service implementation is atomic, but we have this client-side idempotency issue. This fix relies on time and assumes that if the destination was recently updated while we are executing a retry policy, that we succeeded. This may not be the case. For example, users may rely on rename (with overwrite = false) of a file to synchronize or act like a distributed lock, so who ever renames successfully acquires the lock. With the fix in PR 2021, more than one caller could acquire this lock at the same time. Instead, I think we could allow the client to provide a UUID for the rename operation and persist this UUID in the metadata of the destination blob upon successful completion of a rename, then if we get into this idempotency issue and the client gets a 404 source does not exist, we can check the destination blob's metadata to see if the UUID is a match. > ABFS: Make PUT and POST operations idempotent > - > > Key: HADOOP-17015 > URL: https://issues.apache.org/jira/browse/HADOOP-17015 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/azure >Affects Versions: 3.2.1 >Reporter: Sneha Vijayarajan >Assignee: Sneha Vijayarajan >Priority: Major > Fix For: 3.4.0 > > > Currently when a PUT or POST operation timeouts and the server has already > successfully executed the operation, there is no check in driver to see if > the operation did succeed or not and just retries the same operation again. > This can cause driver to through invalid user errors. > > Sample scenario: > # Rename request times out. Though server has successfully executed the > operation. > # Driver retries rename and get source not found error. > In the scenario, driver needs to check if rename is being retried and success > if source if not found, but destination is present. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
[jira] [Created] (HADOOP-17089) WASB: Update azure-storage-java SDK
Thomas Marqardt created HADOOP-17089: Summary: WASB: Update azure-storage-java SDK Key: HADOOP-17089 URL: https://issues.apache.org/jira/browse/HADOOP-17089 Project: Hadoop Common Issue Type: Bug Components: fs/azure Affects Versions: 3.2.0, 3.1.0, 3.0.0, 2.9.0, 2.8.0, 2.7.0 Reporter: Thomas Marqardt Assignee: Thomas Marqardt WASB depends on the Azure Storage Java SDK. There is a concurrency bug in the Azure Storage Java SDK that can cause the results of a list blobs operation to appear empty. This causes the Filesystem listStatus and similar APIs to return empty results. This has been seen in Spark work loads when jobs use more than one executor core. See [https://github.com/Azure/azure-storage-java/pull/546] for details on the bug in the Azure Storage SDK. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
[jira] [Resolved] (HADOOP-17015) ABFS: Make PUT and POST operations idempotent
[ https://issues.apache.org/jira/browse/HADOOP-17015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Marqardt resolved HADOOP-17015. -- Resolution: Fixed Sneha and I discussed this. The common Hadoop scenario is a case where you have one or more tasks, each operating on different source files, all attempting to rename to a common destination. In this scenario, the fix in PR 2021 is correct. There are scenarios where PR 2021 will lead to incorrect results, but they seem to be very contrived and unlikely in Hadoop. A work item will be opened to investigate the need to improve this on the server-side, for example by allowing an operation-id to be passed to the rename operation and persisted in the destination metadata, but for now we have this fix to the driver on the client-side. > ABFS: Make PUT and POST operations idempotent > - > > Key: HADOOP-17015 > URL: https://issues.apache.org/jira/browse/HADOOP-17015 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/azure >Affects Versions: 3.2.1 >Reporter: Sneha Vijayarajan >Assignee: Sneha Vijayarajan >Priority: Major > Fix For: 3.4.0 > > > Currently when a PUT or POST operation timeouts and the server has already > successfully executed the operation, there is no check in driver to see if > the operation did succeed or not and just retries the same operation again. > This can cause driver to through invalid user errors. > > Sample scenario: > # Rename request times out. Though server has successfully executed the > operation. > # Driver retries rename and get source not found error. > In the scenario, driver needs to check if rename is being retried and success > if source if not found, but destination is present. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
[jira] [Resolved] (HADOOP-17089) WASB: Update azure-storage-java SDK
[ https://issues.apache.org/jira/browse/HADOOP-17089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Marqardt resolved HADOOP-17089. -- Fix Version/s: 3.3.1 Release Note: Azure WASB bug fix that can cause list results to appear empty. Resolution: Fixed trunk: commit 4b5b54c73f2fd9146237087a59453e2b5d70f9ed Author: Thomas Marquardt Date: Wed Jun 24 18:37:25 2020 + branch-3.3 commit ee192c48265fe7dcf23bc33f6a6698bb41477ca9 Author: Thomas Marquardt Date: Wed Jun 24 18:37:25 2020 + > WASB: Update azure-storage-java SDK > --- > > Key: HADOOP-17089 > URL: https://issues.apache.org/jira/browse/HADOOP-17089 > Project: Hadoop Common > Issue Type: Bug > Components: fs/azure >Affects Versions: 2.7.0, 2.8.0, 2.9.0, 3.0.0, 3.1.0, 3.2.0 >Reporter: Thomas Marqardt >Assignee: Thomas Marqardt >Priority: Major > Fix For: 3.3.1 > > > WASB depends on the Azure Storage Java SDK. There is a concurrency bug in > the Azure Storage Java SDK that can cause the results of a list blobs > operation to appear empty. This causes the Filesystem listStatus and similar > APIs to return empty results. This has been seen in Spark work loads when > jobs use more than one executor core. > See [https://github.com/Azure/azure-storage-java/pull/546] for details on the > bug in the Azure Storage SDK. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
[jira] [Reopened] (HADOOP-17183) ABFS: Enable checkaccess API
[ https://issues.apache.org/jira/browse/HADOOP-17183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Marqardt reopened HADOOP-17183: -- Tests are failing so I am going to revert this to fix them. Sorry, I did not see a quick fix, so decided to revert for now. > ABFS: Enable checkaccess API > > > Key: HADOOP-17183 > URL: https://issues.apache.org/jira/browse/HADOOP-17183 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/azure >Affects Versions: 3.3.0 >Reporter: Bilahari T H >Assignee: Bilahari T H >Priority: Major > Labels: pull-request-available > Fix For: 3.4.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
[jira] [Resolved] (HADOOP-16915) ABFS: Test failure ITestAzureBlobFileSystemRandomRead.testRandomReadPerformance
[ https://issues.apache.org/jira/browse/HADOOP-16915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Marqardt resolved HADOOP-16915. -- Fix Version/s: 3.4.0 3.3.1 Resolution: Fixed Pushed to trunk in commit 64f36b9 and backported to branch-3.3 in commit cc73503. All tests passing against my account in eastus2euap: namespace.enabled=true auth.type=SharedKey $mvn -T 1C -Dparallel-tests=abfs -Dscale -DtestsThreadCount=8 clean verify Tests run: 88, Failures: 0, Errors: 0, Skipped: 0 Tests run: 457, Failures: 0, Errors: 0, Skipped: 24 Tests run: 208, Failures: 0, Errors: 0, Skipped: 24 namespace.enabled=true auth.type=OAuth $mvn -T 1C -Dparallel-tests=abfs -Dscale -DtestsThreadCount=8 clean verify Tests run: 88, Failures: 0, Errors: 0, Skipped: 0 Tests run: 457, Failures: 0, Errors: 0, Skipped: 66 Tests run: 208, Failures: 0, Errors: 0, Skipped: 141 > ABFS: Test failure > ITestAzureBlobFileSystemRandomRead.testRandomReadPerformance > --- > > Key: HADOOP-16915 > URL: https://issues.apache.org/jira/browse/HADOOP-16915 > Project: Hadoop Common > Issue Type: Sub-task >Reporter: Bilahari T H >Assignee: Bilahari T H >Priority: Major > Labels: abfsactive > Fix For: 3.3.1, 3.4.0 > > > Ref: https://issues.apache.org/jira/browse/HADOOP-16890 > The following test fails randomly. This test compares the perf between Non > HNS account against WASB. > ITestAzureBlobFileSystemRandomRead.testRandomReadPerformance -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
[jira] [Reopened] (HADOOP-17397) ABFS: SAS Test updates for version and permission update
[ https://issues.apache.org/jira/browse/HADOOP-17397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Marqardt reopened HADOOP-17397: -- See my previous comment on why this was reopened. > ABFS: SAS Test updates for version and permission update > > > Key: HADOOP-17397 > URL: https://issues.apache.org/jira/browse/HADOOP-17397 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/azure >Affects Versions: 3.3.0 >Reporter: Sneha Vijayarajan >Assignee: Sneha Vijayarajan >Priority: Major > Labels: pull-request-available > Fix For: 3.3.1 > > Time Spent: 50m > Remaining Estimate: 0h > > This Jira will track the below 2 updates to SAS test code: > # Upgrading the SAS version in Service SAS generator (test code) > # Updating the permission in Delegation SAS to "op" from "p" for ACL > operation as identities added as suoid/saoid added by tests are not owners of > test path (Again test code). > [Relevant public documentation: > https://docs.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas#specify-a-signed-object-id-for-a-security-principal-preview|https://docs.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas#specify-a-signed-object-id-for-a-security-principal-preview] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
[jira] [Resolved] (HADOOP-17397) ABFS: SAS Test updates for version and permission update
[ https://issues.apache.org/jira/browse/HADOOP-17397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Marqardt resolved HADOOP-17397. -- Resolution: Fixed Pushed to trunk (commit 717b8350) and branch-3.3 (commit a5695057). > ABFS: SAS Test updates for version and permission update > > > Key: HADOOP-17397 > URL: https://issues.apache.org/jira/browse/HADOOP-17397 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/azure >Affects Versions: 3.3.0 >Reporter: Sneha Vijayarajan >Assignee: Sneha Vijayarajan >Priority: Major > Labels: pull-request-available > Fix For: 3.3.1 > > Time Spent: 1.5h > Remaining Estimate: 0h > > This Jira will track the below 2 updates to SAS test code: > # Upgrading the SAS version in Service SAS generator (test code) > # Updating the permission in Delegation SAS to "op" from "p" for ACL > operation as identities added as suoid/saoid added by tests are not owners of > test path (Again test code). > [Relevant public documentation: > https://docs.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas#specify-a-signed-object-id-for-a-security-principal-preview|https://docs.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas#specify-a-signed-object-id-for-a-security-principal-preview] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
[jira] [Resolved] (HADOOP-17422) ABFS: Set default ListMaxResults to max server limit
[
https://issues.apache.org/jira/browse/HADOOP-17422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Marqardt resolved HADOOP-17422.
--
Fix Version/s: 3.3.1
Release Note: ABFS: The default value for "fs.azure.list.max.results" was
changed from 500 to 5000.
Resolution: Fixed
commit a35fc387
> ABFS: Set default ListMaxResults to max server limit
>
>
> Key: HADOOP-17422
> URL: https://issues.apache.org/jira/browse/HADOOP-17422
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/azure
>Affects Versions: 3.3.0
>Reporter: Sumangala Patki
>Assignee: Thomas Marqardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.3.1
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> {{Changing the default value of maximum size of }}{{results to be}}{{
> returned by ListStatus from 500 to 5000, since the maximum number of items
> supported by a listStatus server call is 5000.}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org
