测试 Azure WASB 客户端

此模块既包括单元测试(可以在不连接到 Azure 存储服务的情况下独立运行),也包括集成测试(需要工作连接才能与容器进行交互)。单元测试套件遵循命名约定 Test*.java。集成测试遵循命名约定 ITest*.java

提交影响 hadoop-azure 模块的补丁的政策。

由于需要确保凭据安全,Apache Jenkins 基础设施不运行任何云集成测试。

任何补丁的提交者都必须运行所有集成测试并声明他们使用的 Azure 区域。

这一点很重要:不包含此声明的补丁将被忽略

此政策已被证明是保证代码更改完全回归测试的唯一机制。为什么要声明区域?原因有两个

  1. 它帮助我们识别仅针对特定终结点出现的回归。
  2. 它迫使提交者更诚实地对待他们的测试。撒谎很容易,“是的,我测试了这个”。说“是的,我针对 Azure 美国西部测试了这个”是一个更具体的谎言,而且更难说出口。而且,如果你被抓住了:你将失去项目中的所有信誉。

您无需在 Azure 基础设施中的 VM 中进行测试,您只需要凭据即可。

运行测试既不难也不昂贵;如果您不能,则无法保证您的补丁有效。审阅者有足够的事情要做,没有时间做这些测试,特别是每次失败都会导致缓慢的迭代开发。

请:运行测试。如果您不这样做,我们很抱歉拒绝您的补丁,但我们必须这样做。

如果测试间歇性失败怎么办?

一些测试确实会间歇性失败,尤其是在并行运行时。如果发生这种情况,请尝试单独运行测试以查看测试是否成功。

如果仍然失败,请在您的声明中包含此事实。我们知道一些测试间歇性不可靠。

如果测试因我的网络连接而超时或失败,该怎么办?

这些测试被设计为可针对不同的超时时间进行配置。如果你遇到问题并且此配置不起作用,则表明配置机制不完整。如果在生产代码中发生这种情况,则可能表明存在一个问题,该问题可能会在长途连接中出现。请帮助我们识别并解决这些问题——特别是由于你是最适合验证修复工作的人。

设置测试

测试 hadoop-azure 模块

hadoop-azure 模块包含一整套单元测试。许多测试可以通过运行 mvn test 在不进行额外配置的情况下运行。这包括针对模拟存储(Azure 存储的内存仿真)的测试。

集成测试被设计为直接针对 Azure 存储服务进行测试,并且需要一个帐户和凭据才能运行。

这是通过创建文件 src/test/resources/azure-auth-keys.xml 并设置存储帐户的名称及其访问密钥来完成的。

例如

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
  <property>
    <name>fs.azure.wasb.account.name</name>
    <value>{ACCOUNTNAME}.blob.core.windows.net</value>
  </property>
  <property>
    <name>fs.azure.account.key.{ACCOUNTNAME}.blob.core.windows.net</name>
    <value>{ACCOUNT ACCESS KEY}</value>
  </property>
</configuration>

要运行契约测试,请在 src/test/resources/azure-auth-keys.xml 中设置 WASB 文件系统 URI 和帐户访问密钥。例如

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
  <property>
    <name>fs.contract.test.fs.wasb</name>
    <value>wasb://{CONTAINERNAME}@{ACCOUNTNAME}.blob.core.windows.net</value>
    <description>The name of the azure file system for testing.</description>
  </property>
  <property>
    <name>fs.azure.account.key.{ACCOUNTNAME}.blob.core.windows.net</name>
    <value>{ACCOUNT ACCESS KEY}</value>
  </property>
</configuration>

总体而言,要使用 mvn test 运行所有测试,一个示例 azure-auth-keys.xml 如下

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
  <property>
    <name>fs.azure.wasb.account.name</name>
    <value>{ACCOUNTNAME}.blob.core.windows.net</value>
  </property>
  <property>
    <name>fs.azure.account.key.{ACCOUNTNAME}.blob.core.windows.net</name>
    <value>{ACCOUNT ACCESS KEY}</value>
  </property>
  <property>
    <name>fs.contract.test.fs.wasb</name>
    <value>wasb://{CONTAINERNAME}@{ACCOUNTNAME}.blob.core.windows.net</value>
  </property>
</configuration>

不要将 azure-auth-keys.xml 添加到版本控制。Azure 存储帐户的密钥是秘密,不得共享。

运行测试

完成配置后,通过 Maven 执行测试运行。

mvn -T 1C clean verify

还可以通过在命令行上传递 parallel-tests=wasb|abfs|both 属性来并行执行多个测试套件。测试将大部分时间阻塞在网络 I/O 上,因此并行运行往往可以更快地完成完整的测试运行。

mvn -T 1C -Dparallel-tests=both clean verify
mvn -T 1C -Dparallel-tests=wasb clean verify
mvn -T 1C -Dparallel-tests=abfs clean verify

-Dparallel-tests=wasb 从 azure 目录运行 WASB 相关的集成测试

-Dparallel-tests=abfs 从 azurebfs 目录运行 ABFS 相关的集成测试

-Dparallel-tests=both 从 azure 和 azurebfs 目录运行所有集成测试

某些测试必须对存储容器拥有独占访问权限,因此即使使用 parallel-tests 属性,多个测试套件也会在并行测试后的单独 Maven 执行步骤中串行运行。

默认情况下,parallel-tests 并发运行 4 个测试套件。可以通过传递 testsThreadCount 属性来调整此设置。

mvn -T 1C -Dparallel-tests -DtestsThreadCount=8 clean verify
mvn -T 1C clean test

mvn -T 1C -Dparallel-tests clean test

mvn -T 1C -Dparallel-tests -DtestsThreadCount=8 clean test

若要仅运行特定命名的测试子集,请传递 test 属性(用于单元测试)或 it.test 属性(用于集成测试)。

mvn -T 1C clean test -Dtest=TestRollingWindowAverage

mvn -T 1C clean verify -Dscale -Dit.test=ITestFileSystemOperationExceptionMessage -Dtest=none

mvn -T 1C clean verify -Dtest=none -Dit.test=ITest*

注意

  1. 在运行特定测试子集时,testit.test 中传递的模式将覆盖在单独串行阶段中哪些测试需要隔离运行的配置(如上所述)。这可能导致无法预测的结果,因此建议避免将 parallel-teststestit.test 结合使用。如果你知道自己仅指定了可以安全并行运行的测试,那么它将起作用。对于如上所示的 ITest* 等广泛模式,它可能会导致无法预测的测试失败。

  2. 命令行 shell 可能会尝试展开测试模式中的“*”和有时是“#”符号。在这种情况下,用“\”前缀转义该字符。示例

      mvn -T 1C clean verify -Dtest=none -Dit.test=ITest\*
    

查看结果

集成测试结果和日志存储在 target/failsafe-reports/ 中。可以在站点生成期间或使用 surefire-report 插件生成 HTML 报告

# for the unit tests
mvn -T 1C surefire-report:report-only

# for the integration tests
mvn -T 1C surefire-report:failsafe-report-only

# all reports for this module
mvn -T 1C site:site

规模测试

有一组测试旨在衡量文件系统客户端在规模上的可伸缩性和性能,即规模测试。测试包括:创建和遍历目录树、上传大文件、重命名文件、删除文件、在文件中进行查找、执行随机 I/O 等。这使其成为基准测试的基础部分。

它们本质上是缓慢的。而且,由于它们的执行时间通常受运行测试的计算机与 Azure 终结点之间的带宽限制,因此并行执行不会加快这些测试的速度。

启用规模测试

如果在 maven 构建中设置了 scale 属性,则启用测试,无论是否使用并行测试配置文件都可以执行此操作

mvn -T 1C verify -Dscale

mvn -T 1C verify -Dparallel-tests -Dscale -DtestsThreadCount=8

带宽最密集的测试(那些上传数据的测试)始终顺序运行;由于 HTTPS 设置成本或服务器端操作而导致速度较慢的测试包含在并行化测试集中。

规模测试调整选项

某些测试可以从 maven 构建或用于运行测试的配置文件中进行调整。

mvn -T 1C verify -Dparallel-tests -Dscale -DtestsThreadCount=8 -Dfs.azure.scale.test.huge.filesize=128M

算法是

  1. 从配置文件中查询该值,如果未设置,则使用默认值。
  2. 从 JVM 系统属性中查询该值,该值由 maven 传递。
  3. 如果系统属性为 null、空字符串或具有值 unset,则使用配置值。unset 选项用于 解决 maven 属性传播中的一个怪癖

只有少数属性可以这样设置;将添加更多属性。

属性 含义
fs.azure.scale.test.huge.filesize 大型文件上传的大小
fs.azure.scale.test.huge.huge.partitionsize 大型文件上传中分区的大小

文件和分区大小是带 k/m/g/t/p 后缀的数字值,具体取决于所需大小。例如:128M、128m、2G、2G、4T 甚至 1P。

规模测试配置选项

一些规模测试执行多个操作(例如创建多个目录)。

要在选项 scale.test.operation.count 中执行的操作的确切数量是可配置的。

<property>
  <name>scale.test.operation.count</name>
  <value>10</value>
</property>

较大的值会产生更大的负载,并且在本地测试或批量运行时推荐使用。

较小的值会导致更快的测试运行,尤其是在对象存储距离较远时。

针对目录执行的操作具有单独的选项:这控制创建递归目录的测试的宽度和深度。较大的值会创建更多目录,从而对性能产生影响。

<property>
  <name>scale.test.directory.count</name>
  <value>2</value>
</property>

针对 Azure 的 DistCp 测试支持可配置的文件大小。默认值为 10 MB,但配置值以 KB 表示,以便可以调整为更小以实现更快的测试运行。

<property>
  <name>scale.test.distcp.file.size.kb</name>
  <value>10240</value>
</property>

特定于 Azure 的规模测试属性是

fs.azure.scale.test.huge.filesize:用于“大型文件测试”的 MB 大小。

大型文件测试验证 Azure 存储处理大型文件的能力,属性 fs.azure.scale.test.huge.filesize 声明要使用的文件大小。

<property>
  <name>fs.azure.scale.test.huge.filesize</name>
  <value>200M</value>
</property>

此规模的测试很慢:最好从存储端点所在的云基础设施中运行的主机执行这些测试。

使用模拟器

一系列测试可以在 Azure 存储模拟器 上运行,它是实时 Azure 存储的高保真模拟。模拟器足以进行高可信度测试。模拟器是一个在本地计算机上运行的 Windows 可执行文件。

要使用模拟器,请安装 Azure SDK 2.3 并启动存储模拟器。然后,编辑 src/test/resources/azure-test.xml 并添加以下属性

<property>
  <name>fs.azure.test.emulator</name>
  <value>true</value>
</property>

在使用模拟器运行测试时存在已知问题。您可能会看到以下失败消息

com.microsoft.windowsazure.storage.StorageException: The value for one of the HTTP headers is not in the correct format.

要解决此问题,请重新启动 Azure 模拟器。确保它是 v3.2 或更高版本。

调试测试失败

在调试级别记录是提供更多诊断输出的标准方式;在设置此项后重新运行测试

log4j.logger.org.apache.hadoop.fs.azure=DEBUG

添加新测试

新测试始终受欢迎。请记住,我们需要降低成本和测试时间,方法如下

  • 不重复测试。
  • 高效地使用 Hadoop API 调用。
  • 将大型/慢速测试隔离到“scale”测试组中。
  • 设计所有测试以并行执行(如果可能)。
  • 谨慎地向现有测试中添加新探测和谓词。

无重复:如果某个操作在其他地方已测试,请不要重复。这既适用于元数据操作,也适用于批量 I/O。如果添加了一个完全过时的现有测试的新测试用例,则可以删除前一个测试,前提是在显示覆盖率没有恶化之后。

高效:优先使用 getFileStatus() 并检查结果,而不是调用 exists()isFile() 等。

失败时提供有用的信息:在失败时提供尽可能多的诊断信息。使用 org.apache.hadoop.fs.contract.ContractTestUtils 对文件系统的状态进行断言在此处有所帮助。

隔离规模测试。执行大量 I/O 的任何测试都必须扩展类 AbstractAzureScaleTest,因此仅在构建中定义了 scale 时才运行,支持用户可配置的测试超时。规模测试还应支持对象大小/操作数量的配置,以便可以验证不同规模下的行为。

设计用于并行执行。此处的一个关键需求是每个测试套件都应处理文件系统的隔离部分。AbstractWasbTestBase 的子类应使用 path()methodpath()blobpath() 方法来构建隔离路径。测试不得假定它们对存储桶具有独占访问权限。

在适当的情况下扩展现有测试。此建议与“每个方法测试一件事”的正常测试最佳实践相悖。由于创建目录树或上传大文件非常慢,因此我们没有这种奢侈。针对真实端点的所有测试都是集成测试,其中共享测试设置和拆除可以节省时间和金钱。

一种标准的方法是用一些额外的谓词扩展现有测试,而不是编写新测试。执行此操作时,请确保新谓词以有意义的诊断失败,以便可以轻松地从测试日志中调试任何新问题。

新测试的要求

这是我们对新测试的期望;它们是正常 Hadoop 要求的扩展,基于与远程服务器协作的需求,使用这些服务器需要提供机密凭据,测试可能很慢,而且仅从测试输出中找出失败原因至关重要。

子类化现有共享基类

有一组基类应该针对 Azure 测试和集成测试进行扩展。

org.apache.hadoop.fs.azure.AbstractWasbTestWithTimeout

它使用线程名称和超时扩展了 junit Assert 类,默认超时在 AzureTestConstants.AZURE_TEST_TIMEOUT 中设置为十分钟。设置线程名称是为了帮助分析测试的堆栈跟踪:可以使用 jstack 调用来

org.apache.hadoop.fs.azure.AbstractWasbTestBase

使用 AzureBlobStorageTestAccount 创建模拟或实时 Azure 客户端的测试的基类;在测试清理中,它尝试清理存储状态。

  1. 此类要求子类实现 createTestAccount() 以创建一个模拟或真实的测试帐户。

  2. 用于创建一个测试帐户的配置应该来自 createConfiguration();这可以在子类中进行扩展以调整设置。

org.apache.hadoop.fs.azure.integration.AbstractAzureScaleTest

它为规模测试扩展了 AbstractWasbTestBase;仅当使用 -Dscale 来选择“规模”配置文件时才运行这些测试。这些测试的超时时间为 30 分钟,以便支持慢速测试运行。

共享基类有助于减少将来的维护工作。请使用它们。

安全

切勿记录凭据。凭据测试会想方设法不提供有意义的日志或断言消息,以避免这种情况。

时间和金钱的效率

这意味着在测试设置/清理中提高效率,理想情况下,利用现有的公共数据集来节省设置时间和测试人员成本。

参考示例是 ITestAzureHugeFiles:. 这将测试套件标记为 @FixMethodOrder(MethodSorters.NAME_ASCENDING),然后对测试用例进行排序,以便每个测试用例都期望前一个测试已完成(此处:上传文件、重命名文件,…)。这在报告中提供了独立的测试,但仍然允许按顺序执行操作。请注意使用 Assume.assume() 来检测何时不满足单个测试用例的先决条件,因此,测试会被跳过,而不是失败并产生实际上是错误警报的跟踪。

在长途链路上运行

除了使文件大小和操作计数可扩展,这还包括使测试超时变得足够。Scale 测试使之可配置;在 AbstractAzureIntegrationTest() 中硬编码为十分钟;子类可以通过覆盖 getTestTimeoutMillis() 来更改此设置。

同样重要的是:支持代理,因为某些测试人员需要它们。

提供诊断和计时信息

  1. 创建日志,记录内容。
  2. 您可以在此处使用 AbstractWasbTestBase.describe(format-string, args);它添加了一些新行,以便于发现。
  3. 使用 ContractTestUtils.NanoTimer 测量操作的持续时间,并记录输出。

有意义地失败

ContractTestUtils 类包含一整套断言,用于对文件系统的预期状态进行说明,例如 assertPathExists(FS, path)assertPathDoesNotExists(FS, path) 等。这些断言尽力在发生故障时提供有意义的诊断(例如目录列表、文件状态等),从而有助于让人们更容易理解故障。

至少,不要在不包含错误消息的情况下使用 assertTrue()assertFalse()

随后进行清理

降低成本。

  1. 不要仅在测试用例成功完成后进行清理;测试套件拆除必须执行此操作。
  2. 拆除代码必须在清理前检查文件系统和其他字段是否为 null。为什么?如果测试设置失败,仍然会调用拆除方法。

可靠地工作

我们非常感谢这一点——您也会感谢的。

提示

如何让您的凭据真正安全

尽管 auth-keys.xml 文件被标记为在 git 和 subversion 中忽略,但它仍然在您的源代码树中,并且始终存在它可能泄露的风险。

您可以通过将密钥保存在源代码树外部并使用绝对 XInclude 引用来避免这种情况。

<configuration>

  <include xmlns="http://www.w3.org/2001/XInclude"
    href="file:///users/qe/.auth-keys.xml" />

</configuration>

清理容器

Azure 测试使用前缀 "wasbtests-" 创建容器,并在测试运行后删除它们。如果测试运行中断,这些容器可能不会被删除。有一个特殊测试用例可以手动调用来列出并删除这些容器,CleanupTestContainers

mvn test -Dtest=CleanupTestContainers

这将删除容器;测试运行的输出日志将提供操作的详细信息和摘要。

测试 Azure ABFS 客户端

Azure Data Lake Storage Gen 2 (ADLS Gen 2) 是一组专用于大数据分析的功能,建立在 Azure Blob Storage 之上。ABFS 和 ABFSS 方案针对 ADLS Gen 2 REST API,WASB 和 WASBS 方案针对 Azure Blob Storage REST API。ADLS Gen 2 提供更好的性能和可扩展性。当为存储帐户启用分层命名空间时,ADLS Gen 2 还提供与 Hadoop 分布式文件系统权限模型兼容的身份验证和授权。此外,ADLS Gen 2 REST API 产生的元数据和数据可以被 Blob REST API 使用,反之亦然。

在各种配置组合上生成测试运行配置和测试触发器

为了简化对公关所需的各种身份验证和功能组合的测试,应使用脚本 dev-support/testrun-scripts/runtests.sh。一旦使用各种测试组合的相关配置设置更新脚本,它将:1. 自动生成特定于每个测试组合的配置 2. 针对所有组合运行测试 3. 汇总所有测试组合运行的结果。

作为先决条件步骤,请填写 src/test/resources/azure-auth-keys.xml.template 中身份验证所需的测试帐户和凭据的配置值,并重命名为 src/test/resources/azure-auth-keys.xml

要添加新的测试组合:公关验证的强制性测试组合的模板存在于 dev-support/testrun-scripts/runtests.sh 中。如果需要添加新的测试组合,请在 dev-support/testrun-scripts/runtests.sh 中添加一个组合集,类似于已定义的组合,并且 1. 提供新的组合名称 2. 更新对测试组合有效的属性和值数组 3. 调用 generateconfigs

要运行公关验证:运行命令 * dev-support/testrun-scripts/runtests.sh 将为定义的每个组合生成配置,并针对所有组合运行测试。* dev-support/testrun-scripts/runtests.sh -c {combinationname} 可以使用 -c 选项提供特定的组合。如果使用 -c 选项提供了组合,则只会针对这些组合运行测试。

测试日志:测试运行将在 dev-support/testlogs 中创建一个文件夹来保存测试日志。文件夹名称将是测试开始时间戳。每个组合的 mvn verify 命令行日志将保存到该文件夹中的 Test-Logs-$combination.txt 文件中。如果出现任何故障,此文件将包含故障异常堆栈。在测试运行结束时,所有组合运行的合并结果将保存到同一文件夹中的 Test-Results.log 文件中。当为 PR 验证运行时,合并的测试结果需要粘贴到 PR 评论部分。

为在 IDE 中使用生成配置:使用 -a(激活)选项运行命令 dev-support/testrun-scripts/runtests.sh -a {combination name} 将更新与特定测试组合相关的有效配置。因此,mvn 测试运行使用的相同配置文件可用于 IDE,而无需在配置文件中进行任何手动更新。

其他命令行选项: * -a <COMBINATION_NAME> 指定需要激活的组合名称。这用于为在 IDE 中使用生成配置。 * -c <COMBINATION_NAME> 为测试运行指定组合名称。如果指定此配置,则仅运行指定组合的测试。如果未指定此配置,将运行所有组合的测试。 * -t <THREAD_COUNT> ABFS mvn 测试以并行模式运行。默认情况下,测试以 8 个线程数运行。可以通过提供 -t <THREAD_COUNT> 来更改它。

为了测试 ABFS,请将以下配置添加到 src/test/resources/azure-auth-keys.xml 文件中。请注意,除了 ABFS 凭据外,ABFS 测试还包括需要 WASB 凭据的兼容性测试。

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration xmlns:xi="http://www.w3.org/2001/XInclude">
  <property>
    <name>fs.azure.abfs.account.name</name>
    <value>{ACCOUNT_NAME}.dfs.core.windows.net</value>
  </property>

  <property>
    <name>fs.azure.account.key.{ACCOUNT_NAME}.dfs.core.windows.net</name>
    <value>{ACCOUNT_ACCESS_KEY}</value>
  </property>

  <property>
    <name>fs.azure.wasb.account.name</name>
    <value>{ACCOUNT_NAME}.blob.core.windows.net</value>
  </property>

  <property>
    <name>fs.azure.account.key.{ACCOUNT_NAME}.blob.core.windows.net</name>
    <value>{ACCOUNT_ACCESS_KEY}</value>
  </property>

  <property>
    <name>fs.contract.test.fs.abfs</name>
    <value>abfs://{CONTAINER_NAME}@{ACCOUNT_NAME}.dfs.core.windows.net</value>
    <description>A file system URI to be used by the contract tests.</description>
  </property>

  <property>
    <name>fs.contract.test.fs.wasb</name>
    <value>wasb://{CONTAINER_NAME}@{ACCOUNT_NAME}.blob.core.windows.net</value>
    <description>A file system URI to be used by the contract tests.</description>
  </property>
</configuration>

要运行 OAuth 和 ACL 测试用例,你必须使用启用了层次命名空间的存储帐户,并设置以下配置设置

<!--=========================== AUTHENTICATION  OPTIONS ===================-->
<!--ATTENTION:
      TO RUN ABFS & WASB COMPATIBILITY TESTS, YOU MUST SET AUTH TYPE AS SharedKey.
      OAUTH IS INTRODUCED TO ABFS ONLY.-->
<property>
  <name>fs.azure.account.auth.type.{YOUR_ABFS_ACCOUNT_NAME}</name>
  <value>{AUTH TYPE}</value>
  <description>The authorization type can be SharedKey, OAuth, Custom or SAS. The
  default is SharedKey.</description>
</property>

<!--=============================   FOR OAUTH   ===========================-->
<!--IF AUTH TYPE IS SET AS OAUTH, FOLLOW THE STEPS BELOW-->
<!--NOTICE: AAD client and tenant related properties can be obtained through Azure Portal-->

  <!--1. UNCOMMENT BELOW AND CHOOSE YOUR OAUTH PROVIDER TYPE -->

  <!--
  <property>
    <name>fs.azure.account.oauth.provider.type.{ABFS_ACCOUNT_NAME}</name>
    <value>org.apache.hadoop.fs.azurebfs.oauth2.{Token Provider Class name}</value>
    <description>The full name of token provider class name.</description>
  </property>
 -->

  <!--2. UNCOMMENT BELOW AND SET CREDENTIALS ACCORDING TO THE PROVIDER TYPE-->

  <!--2.1. If "ClientCredsTokenProvider" is set as key provider, uncomment below and
           set auth endpoint, client id and secret below-->
  <!--
   <property>
    <name>fs.azure.account.oauth2.client.endpoint.{ABFS_ACCOUNT_NAME}</name>
    <value>https://login.microsoftonline.com/{TENANTID}/oauth2/token</value>
    <description>Token end point, this can be found through Azure portal</description>
  </property>

   <property>
     <name>fs.azure.account.oauth2.client.id.{ABFS_ACCOUNT_NAME}</name>
     <value>{client id}</value>
     <description>AAD client id.</description>
   </property>

   <property>
     <name>fs.azure.account.oauth2.client.secret.{ABFS_ACCOUNT_NAME}</name>
     <value>{client secret}</value>
   </property>
 -->

  <!--2.2. If "UserPasswordTokenProvider" is set as key provider, uncomment below and
           set auth endpoint, use name and password-->
  <!--
   <property>
    <name>fs.azure.account.oauth2.client.endpoint.{ABFS_ACCOUNT_NAME}</name>
    <value>https://login.microsoftonline.com/{TENANTID}/oauth2/token</value>
    <description>Token end point, this can be found through Azure portal</description>
  </property>

   <property>
     <name>fs.azure.account.oauth2.user.name.{ABFS_ACCOUNT_NAME}</name>
     <value>{user name}</value>
   </property>

   <property>
     <name>fs.azure.account.oauth2.user.password.{ABFS_ACCOUNT_NAME}</name>
     <value>{user password}</value>
   </property>
 -->

  <!--2.3. If "MsiTokenProvider" is set as key provider, uncomment below and
           set tenantGuid and client id.-->
  <!--
   <property>
     <name>fs.azure.account.oauth2.msi.tenant.{ABFS_ACCOUNT_NAME}</name>
     <value>{tenantGuid}</value>
     <description>msi tenantGuid.</description>
   </property>

   <property>
     <name>fs.azure.account.oauth2.client.id.{ABFS_ACCOUNT_NAME}</name>
     <value>{client id}</value>
     <description>AAD client id.</description>
   </property>
  -->

  <!--2.4. If "RefreshTokenBasedTokenProvider" is set as key provider, uncomment below and
           set refresh token and client id.-->
  <!--
   <property>
     <name>fs.azure.account.oauth2.refresh.token.{ABFS_ACCOUNT_NAME}</name>
     <value>{refresh token}</value>
     <description>refresh token.</description>
   </property>

   <property>
     <name>fs.azure.account.oauth2.client.id.{ABFS_ACCOUNT_NAME}</name>
     <value>{client id}</value>
     <description>AAD client id.</description>
   </property>
  -->

  <!--
    <property>
        <name>fs.azure.identity.transformer.enable.short.name</name>
        <value>true/false</value>
        <description>
          User principal names (UPNs) have the format “{alias}@{domain}”.
          If true, only {alias} is included when a UPN would otherwise appear in the output
          of APIs like getFileStatus, getOwner, getAclStatus, etc, default is false.
        </description>
    </property>

    <property>
        <name>fs.azure.identity.transformer.domain.name</name>
        <value>domain name of the user's upn</value>
        <description>
          If the domain name is specified and “fs.azure.identity.transformer.enable.short.name”
          is true, then the {alias} part of a UPN can be specified as input to APIs like setOwner,
          setAcl, modifyAclEntries, or removeAclEntries, and it will be transformed to a UPN by appending @ and the domain specified by
          this configuration property.
        </description>
    </property>

    <property>
        <name>fs.azure.identity.transformer.service.principal.id</name>
        <value>service principal object id</value>
        <description>
          An Azure Active Directory object ID (oid) used as the replacement for names contained
          in the list specified by “fs.azure.identity.transformer.service.principal.substitution.list”.
          Notice that instead of setting oid, you can also set $superuser here.
        </description>
    </property>

    <property>
        <name>fs.azure.identity.transformer.skip.superuser.replacement</name>
        <value>true/false</value>
        <description>
          If false, “$superuser” is replaced with the current user when it appears as the owner
          or owning group of a file or directory. The default is false.
        </description>
    </property>

    <property>
        <name>fs.azure.identity.transformer.service.principal.substitution.list</name>
        <value>mapred,hdfs,yarn,hive,tez</value>
        <description>
           A comma separated list of names to be replaced with the service principal ID specified by
           “fs.azure.identity.transformer.service.principal.id”.  This substitution occurs
           when setOwner, setAcl, modifyAclEntries, or removeAclEntries are invoked with identities
           contained in the substitution list. Notice that when in non-secure cluster, asterisk symbol *
           can be used to match all user/group.
        </description>
    </property>
   -->

要运行委派 SAS 测试用例,你必须使用启用了层次命名空间的存储帐户,并设置以下配置设置

<!--=========================== AUTHENTICATION  OPTIONS ===================-->
<!--=============================   FOR SAS   ===========================-->
<!-- To run ABFS Delegation SAS tests, you must register an app, create the
     necessary role assignments, and set the configuration discussed below:

    1) Register an app:
      a) Login to https://portal.azure.com, select your AAD directory and search for app registrations.
      b) Click "New registration".
      c) Provide a display name, such as "abfs-app".
      d) Set the account type to "Accounts in this organizational directory only ({YOUR_Tenant} only - Single tenant)".
      e) For Redirect URI select Web and enter "http://localhost".
      f) Click Register.

    2)  Create necessary role assignments:
      a) Login to https://portal.azure.com and find the Storage account with hierarchical namespace enabled
         that you plan to run the tests against.
      b) Select "Access Control (IAM)".
      c) Select Role Assignments
      d) Click Add and select "Add role assignments"
      e) For Role and enter "Storage Blob Data Owner".
      f) Under Select enter the name of the app you registered in step 1 and select it.
      g) Click Save.
      h) Repeat above steps to create a second role assignment for the app but this time for
         the "Storage Blob Delegator" role.

    3) Generate a new client secret for the application:
      a) Login to https://portal.azure.com and find the app registered in step 1.
      b) Select "Certificates and secrets".
      c) Click "New client secret".
      d) Enter a description (eg. Secret1)
      e) Set expiration period.  Expires in 1 year is good.
      f) Click Add
      g) Copy the secret and expiration to a safe location.

    4) Set the following configuration values:
-->

  <property>
    <name>fs.azure.sas.token.provider.type</name>
    <value>org.apache.hadoop.fs.azurebfs.extensions.MockDelegationSASTokenProvider</value>
    <description>The fully qualified class name of the SAS token provider implementation.</description>
  </property>

  <property>
    <name>fs.azure.test.app.service.principal.tenant.id</name>
    <value>{TID}</value>
    <description>Tenant ID for the application's service principal.</description>
  </property>

  <property>
    <name>fs.azure.test.app.service.principal.object.id</name>
    <value>{OID}</value>
    <description>Object ID for the application's service principal.</description>
  </property>

  <property>
    <name>fs.azure.test.app.id</name>
    <value>{app id}</value>
    <description>The application's ID, also known as the client id.</description>
  </property>

   <property>
     <name>fs.azure.test.app.secret</name>
     <value>{client secret}</value>
     <description>The application's secret, also known as the client secret.</description>
   </property>


要运行 CheckAccess 测试用例,你必须注册一个没有 RBAC 的应用,并设置以下配置。

<!--===========================   FOR CheckAccess =========================-->
<!-- To run ABFS CheckAccess SAS tests, you must register an app, with no role
 assignments, and set the configuration discussed below:

    1) Register a new app with no RBAC
    2) As part of the test configs you need to provide the guid for the above
created app. Please follow the below steps to fetch the guid.
      a) Get an access token with the above created app. Please refer the
 following documentation for the same. https://docs.microsoft
.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow#get-a-token
      b) Decode the token fetched with the above step. You may use https
://jwt.ms/ to decode the token
      d) The oid field in the decoded string is the guid.
    3) Set the following configurations:
-->

  <property>
    <name>fs.azure.enable.check.access</name>
    <value>true</value>
    <description>By default the check access will be on. Checkaccess can
    be turned off by changing this flag to false.</description>
  </property>
  <property>
    <name>fs.azure.account.test.oauth2.client.id</name>
    <value>{client id}</value>
    <description>The client id(app id) for the app created on step 1
    </description>
  </property>
  <property>
    <name>fs.azure.account.test.oauth2.client.secret</name>
    <value>{client secret}</value>
    <description>
The client secret(application's secret) for the app created on step 1
    </description>
  </property>
  <property>
    <name>fs.azure.check.access.testuser.guid</name>
    <value>{guid}</value>
    <description>The guid fetched on step 2</description>
  </property>
  <property>
    <name>fs.azure.account.oauth2.client.endpoint.{account name}.dfs.core
.windows.net</name>
    <value>https://login.microsoftonline.com/{TENANTID}/oauth2/token</value>
    <description>
Token end point. This can be found through Azure portal. As part of CheckAccess
test cases. The access will be tested for an FS instance created with the
above mentioned client credentials. So this configuration is necessary to
create the test FS instance.
    </description>
  </property>

如果针对使用 URL 格式 http[s]://[ip]:[port]/[account]/[filesystem] 而不是 http[s]://[account][domain-suffix]/[filesystem] 的端点运行测试,请使用以下内容

<property>
  <name>fs.azure.abfs.endpoint</name>
  <value>{IP}:{PORT}</value>
</property>