hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-16005) NativeAzureFileSystem does not support setXAttr
Date Fri, 22 Feb 2019 19:16:01 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-16005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16775522#comment-16775522

Steve Loughran commented on HADOOP-16005:

bq.  why don't we send PR through github? Seems it is better than what we do today: upload/download
patch, make comments in text box.

Github integration with yetus is only just coming together. HADOOP-16035 was the latest change.
We don't just want review in there, we need yetus to kick off a test run; the move of the
asf repo to g

now one little bit of fun: someone has somehow done a successful merge through git of a patch,
but it ends up signed by the github key, whereas those of us who have been doing commit -S
get it signed with our local keys, so giving an audit log of who really committed a patch.

Compare: git show --show-signature d33f0666f66  

With: git show --show-signature a868f59d523  

Mixed feelings there. I like the one-click merge, and I wasn't trying to be strict about code
signing, happy. But I am used to GPG signing all commits these days. I think what I'd really
like is some way client side to do a PR merge from github. There's probably a way, but....

> NativeAzureFileSystem does not support setXAttr
> -----------------------------------------------
>                 Key: HADOOP-16005
>                 URL: https://issues.apache.org/jira/browse/HADOOP-16005
>             Project: Hadoop Common
>          Issue Type: Sub-task
>          Components: fs/azure
>            Reporter: Clemens Wolff
>            Assignee: Clemens Wolff
>            Priority: Major
> When interacting with Azure Blob Storage via the Hadoop FileSystem client, it's currently
(as of [a8bbd81|https://github.com/apache/hadoop/commit/a8bbd818d5bc4762324bcdb7cf1fdd5c2f93891b])
not possible to set custom metadata attributes.
> Here is a snippet that demonstrates the missing behavior (throws an UnsupportedOperationException):
> {code:java}
> val blobAccount = "SET ME"
> val blobKey = "SET ME"
> val blobContainer = "SET ME"
> val blobFile = "SET ME"
> import org.apache.hadoop.conf.Configuration
> import org.apache.hadoop.fs.{FileSystem, Path}
> val conf = new Configuration()
> conf.set("fs.wasbs.impl", "org.apache.hadoop.fs.azure.NativeAzureFileSystem")
> conf.set(s"fs.azure.account.key.$blobAccount.blob.core.windows.net", blobKey)
> val path = new Path(s"wasbs://$blobContainer@$blobAccount.blob.core.windows.net/$blobFile")
> val fs = FileSystem.get(path, conf)
> fs.setXAttr(path, "somekey", "somevalue".getBytes)
> {code}
> Looking at the code in hadoop-tools/hadoop-azure, NativeAzureFileSystem inherits the
default setXAttr from FileSystem which throws the UnsupportedOperationException.
> The underlying Azure Blob Storage service does support custom metadata ([service docs|https://docs.microsoft.com/en-us/azure/storage/blobs/storage-properties-metadata])
as does the azure-storage SDK that's being used by NativeAzureFileSystem ([SDK docs|http://javadox.com/com.microsoft.azure/azure-storage/2.0.0/com/microsoft/azure/storage/blob/CloudBlob.html#setMetadata(java.util.HashMap)]).
> Is there another way that I should be setting custom metadata on Azure Blob Storage files?
Is there a specific reason why setXAttr hasn't been implemented on NativeAzureFileSystem?
If not, I can take a shot at implementing it.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org

View raw message