測試 Azure WASB 應用程式

此模組包含單元測試,可以在不連線到 Azure Storage 服務的情況下獨立執行,以及整合測試,需要建立連線才能與容器互動。單元測試套件遵循命名慣例 Test*.java。整合測試遵循命名慣例 ITest*.java

提交影響 hadoop-azure 模組的補丁的政策。

Apache Jenkins 基礎架構不會執行任何雲端整合測試,因為需要確保憑證安全。

任何補丁的提交者都必須執行所有整合測試,並宣告他們使用的 Azure 區域。

這很重要:不包含此宣告的補丁將會被忽略

此政策已被證明是保證完整回歸測試程式碼變更的唯一機制。為什麼要宣告區域?原因有兩個

  1. 它有助於我們找出只針對特定端點浮現的回歸。
  2. 它迫使提交者更誠實地進行測試。很容易說謊,「是的,我測試過了」。說「是的,我針對 Azure 美國西部測試過了」是一個更具體的謊言,而且更難說出口。而且,如果你被抓到了:你將失去專案的所有信譽。

你不需要在 Azure 基礎架構中的虛擬機器中進行測試,你只需要憑證即可。

執行測試既不困難也不昂貴;如果你無法執行,則無法保證你的補丁有效。審查者有足夠的工作要做,而且沒有時間執行這些測試,特別是因為每次失敗只會導致緩慢的迭代開發。

請執行測試。如果你沒有執行,我們很抱歉拒絕你的補丁,但我們必須這麼做。

如果測試間歇性失敗怎麼辦?

有些測試確實會間歇性失敗,特別是在並行執行時。如果發生這種情況,請嘗試單獨執行測試,看看測試是否成功。

如果仍然失敗,請在你的宣告中包含此事實。我們知道有些測試間歇性地不可靠。

如果測試因我的網路連線而逾時或失敗怎麼辦?

測試可針對不同的逾時情況進行設定。如果您遇到問題,而且此設定無法解決,這表示設定機制尚未完成。如果在製作程式碼中發生此情況,這可能是問題的徵兆,可能會在長途連線中浮現。請協助我們找出並修正這些問題,特別是因為您是最適合驗證修正程式運作的人員。

設定測試

測試 hadoop-azure 模組

hadoop-azure 模組包含一整套單元測試。許多測試會在執行 mvn test 時,無需其他設定即可執行。這包括針對模擬儲存的測試,這是 Azure Storage 的記憶體中模擬。

整合測試旨在直接針對 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 Storage 帳戶的金鑰是機密,不得分享。

執行測試

完成設定後,透過 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. 命令列殼層可能會嘗試擴充測試模式中的「*」和有時是「#」符號。在這種情況下,請使用「\」前綴來跳脫字元。範例

      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

規模測試

有一組測試旨在衡量檔案系統用戶端在規模上的可擴充性和效能,稱為「規模測試」。測試包括:建立和瀏覽目錄樹、上傳大型檔案、重新命名檔案、刪除檔案、搜尋檔案、執行隨機 IO 等。這讓它們成為基準測試的基礎部分。

它們本質上很慢。而且,由於執行時間通常受到執行測試的電腦和 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 Storage 模擬器 上執行,該模擬器是 Azure Storage 的高保真模擬。模擬器足以進行高可信度測試。模擬器是一個在本地機器上執行的 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 呼叫。
  • 將大型/慢速測試隔離到「規模」測試群組中。
  • 設計所有測試以並行執行(如果可能)。
  • 小心地將新的探測和謂詞新增到現有測試中。

不重複:如果某個作業已在其他地方測試過,請不要重複測試。這適用於大量 IO 的元資料作業。如果新增的測試案例完全取代現有的測試,則可以刪除前一個測試,但必須先顯示涵蓋範圍沒有惡化。

有效率:優先使用 getFileStatus() 並檢查結果,而不是呼叫 exists()isFile() 等。

失敗時提供有用的資訊:在失敗時提供盡可能多的診斷。使用 org.apache.hadoop.fs.contract.ContractTestUtils 來對檔案系統的狀態進行斷言,這在這裡有幫助。

隔離規模測試。執行大量 IO 的任何測試都必須延伸類別 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() 來偵測單一測試案例的前提條件是否未滿足,因此,測試會略過,而不是失敗,而失敗的追蹤實際上是錯誤警報。

在長途連結上運作

除了讓檔案大小和作業計數可擴充之外,這還包括讓測試逾時適當。擴充測試會讓這項功能可設定;它在 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 Client

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 Distributed File System 權限模型相容的驗證和授權。此外,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 {組合名稱} 可以使用 -c 選項提供特定組合。如果使用 -c 選項提供組合,則僅會執行這些組合的測試。

測試記錄:測試執行會在 dev-support/testlogs 中建立一個資料夾來儲存測試記錄。資料夾名稱將是測試開始時間戳記。每個組合的 mvn verify 指令列記錄將儲存到此資料夾中的 Test-Logs-$組合.txt 檔案中。如果發生任何失敗,此檔案將包含失敗例外堆疊。在測試執行結束時,所有組合執行的彙總結果將儲存到同一個資料夾中的 Test-Results.log 檔案中。當執行公關驗證時,彙總的測試結果需要貼到公關留言部分。

產生供 IDE 使用的設定檔:使用 -a (啟用) 選項執行指令 dev-support/testrun-scripts/runtests.sh -a {組合名稱} 將更新與特定測試組合相關的有效設定檔。因此,mvn 測試執行所使用的相同設定檔可用於 IDE,而無需在設定檔中進行任何手動更新。

其他指令列選項: * -a <組合名稱> 指定需要啟用的組合名稱。這用於產生供 IDE 使用的設定檔。 * -c <組合名稱> 指定測試執行的組合名稱。如果指定此設定檔,則僅會執行指定組合的測試。如果未指定此設定檔,則將執行所有組合的測試。 * -t <執行緒數目> ABFS mvn 測試以平行模式執行。預設以 8 個執行緒數目執行測試。可以透過提供 -t <執行緒數目> 來變更。

為了測試 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 "https://127.0.0.1".
      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>