You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@inlong.apache.org by do...@apache.org on 2021/11/24 11:38:37 UTC

[incubator-inlong-website] branch master updated: [INLONG-1661][Improve][translation] the guide of how-to-verify should be translated into English (#198)

This is an automated email from the ASF dual-hosted git repository.

dockerzhang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-inlong-website.git


The following commit(s) were added to refs/heads/master by this push:
     new 1651e78  [INLONG-1661][Improve][translation] the guide of how-to-verify should be translated into English (#198)
1651e78 is described below

commit 1651e78ce8f3308288c3802cf0ae01879b50506f
Author: gosonzhang <46...@qq.com>
AuthorDate: Wed Nov 24 19:38:28 2021 +0800

    [INLONG-1661][Improve][translation] the guide of how-to-verify should be translated into English (#198)
---
 development/how-to-verify.md                       | 112 +++++++++++----------
 .../tubemq/client_partition_assign_introduction.md |   5 +
 .../tubemq/client_partition_assign_introduction.md |   7 +-
 3 files changed, 71 insertions(+), 53 deletions(-)

diff --git a/development/how-to-verify.md b/development/how-to-verify.md
index 2ca38b9..2b95bb7 100644
--- a/development/how-to-verify.md
+++ b/development/how-to-verify.md
@@ -1,39 +1,49 @@
 ---
-title: How to Verify
+title: How to Verify release
 sidebar_position: 7
 ---
 
-# 验证候选版本
+# Verify Apache Release
+To verify the release, the following checklist can be used to reference:
+- [ ] Download links are valid.
+- [ ] Checksums and PGP signatures are valid.
+- [ ] DISCLAIMER-WIP is included.
+- [ ] Source code artifacts have correct names matching the current release.
+- [ ] LICENSE and NOTICE files are correct for the repository.
+- [ ] All files have license headers if necessary.
+- [ ] No compiled archives bundled in source archive.
+- [ ] Building is OK.
 
-<font color="#dd0000" size="4">TODO: This page needs to be translated into English. If you are interested, just do it.</font>
+For a detailed checklist, please refer to [check list](https://cwiki.apache.org/confluence/display/INCUBATOR/Incubator+Release+Checklist), here we introduce how to do the verification.
 
-详细的检查列表请参考: [check list](https://cwiki.apache.org/confluence/display/INCUBATOR/Incubator+Release+Checklist)
-
-## 1. 下载要发布的候选版本到本地环境
+## 1. Download the release package to be verified to the local environment
+> Use the following command to download all artifacts, replace "${release_version}-${rc_version}" with the version ID of the version to be released:
 ```shell
 svn co https://dist.apache.org/repos/dist/dev/incubator/inlong/${release_version}-${rc_version}/
 ```
-## 2. 验证上传的版本是否合规
-> 开始验证环节,验证包含但不局限于以下内容和形式
 
-### 2.1 查看发布包是否完整
-> 上传到dist的包必须包含源码包,二进制包可选
+## 2. Verify signature and hash
+> Start the verification process, which includes but is not limited to the following content and verification methods.
+> GnuPG is recommended, which can install by yum install gnupg or apt-get install gnupg.
 
-1. 是否包含源码包
-2. 是否包含源码包的签名
-3. 是否包含源码包的sha512
-4. 如果上传了二进制包,则同样检查(2)-(4)所列的内容
+### 2.1 Check if the release package is complete
+The package to release must check:
+- Whether to include the source code package
+- Whether to include the signature of the source code package
+- Whether to include the sha512 of the source code package
+- (if include) Check the binary package, also check the contents listed in (2)-(4)
 
-### 2.2 检查gpg签名
-  - 导入公钥
+### 2.2 Verify signature and hash
+GnuPG is recommended, which can install by yum install GnuPG or apt-get install GnuPG.
+  - Import public key
   ```shell
-  curl https://dist.apache.org/repos/dist/dev/incubator/inlong/KEYS > KEYS # 下载KEYS
-  gpg --import KEYS # 导入KEYS到本地
+  curl https://dist.apache.org/repos/dist/dev/incubator/inlong/KEYS > KEYS # Download KEYS
+  gpg --import KEYS # Import KEYS to local
   ```
-  - 信任公钥
-  > 信任此次版本所使用的KEY
+  - Trust the public key
+  > Trust the KEY used in this version
   ```shell
-    gpg --edit-key xxxxxxxxxx #此次版本所使用的KEY
+    gpg --edit-key xxxxxxxxxx                           # KEY used in this version
     gpg (GnuPG) 2.2.21; Copyright (C) 2020 Free Software Foundation, Inc.
     This is free software: you are free to change and redistribute it.
     There is NO WARRANTY, to the extent permitted by law.
@@ -47,7 +57,7 @@ svn co https://dist.apache.org/repos/dist/dev/incubator/inlong/${release_version
          created: 2020-05-19  expires: never       usage: E   
     [ultimate] (1). Guangxu Cheng <gx...@apache.org>
     
-    gpg> trust #信任
+    gpg> trust                                          # Trust the KEY
     sec  rsa4096/5EF3A66D57EC647A
          created: 2020-05-19  expires: never       usage: SC  
          trust: ultimate      validity: ultimate
@@ -65,8 +75,8 @@ svn co https://dist.apache.org/repos/dist/dev/incubator/inlong/${release_version
       5 = I trust ultimately
       m = back to the main menu
     
-    Your decision? 5 #选择5
-    Do you really want to set this key to ultimate trust? (y/N) y #选择y
+    Your decision? 5                                                    # select 5
+    Do you really want to set this key to ultimate trust? (y/N) y       # select y
                                                                  
     sec  rsa4096/5EF3A66D57EC647A
          created: 2020-05-19  expires: never       usage: SC  
@@ -84,17 +94,17 @@ svn co https://dist.apache.org/repos/dist/dev/incubator/inlong/${release_version
          created: 2020-05-19  expires: never       usage: E   
     [ultimate] (1). Guangxu Cheng <gx...@apache.org>
   ```
-  - 使用如下命令检查签名
+  - Check signature and hash
   ```shell
   for i in *.tar.gz; do echo $i; gpg --verify $i.asc $i ; done
-  #或者
+  # or
   gpg --verify apache-inlong-${release_version}-src.tar.gz.asc apache-inlong-${release_version}-src.tar.gz
-  # 如果上传二进制包,则同样需要检查二进制包的签名是否正确
+  # Attention: if you upload a binary package, you also need to check whether the signature of the binary package is correct
   gpg --verify apache-inlong-server-${release_version}-bin.tar.gz.asc apache-inlong-server-${release_version}-bin.tar.gz
   gpg --verify apache-inlong-client-${release_version}-bin.tar.gz.asc apache-inlong-client-${release_version}-bin.tar.gz
 ```
-  - 检查结果
-  > 出现类似以下内容则说明签名正确,关键字:**`Good signature`**
+  - Confirm result
+  > If something similar to the following appears, it means that the signature is correct, and the keywords: **`Good signature`**
 ```shell
 apache-inlong-0.3.0-incubating-src.tar.gz
 gpg: Signature made Sat May 30 11:45:01 2020 CST
@@ -102,36 +112,34 @@ gpg:                using RSA key 9B12C2228BDFF4F4CFE849445EF3A66D57EC647A
 gpg: Good signature from "Guangxu Cheng <gx...@apache.org>" [ultimate]gular2
 ```
 
-### 2.3 检查sha512哈希
-> 本地计算sha512哈希后,验证是否与dist上的一致
+### 2.3 Verify sha512 hash
+> Calculate the sha512 hash locally, and verify that it is consistent with the one on dist
 ```shell
 for i in *.tar.gz; do echo $i; gpg --print-md SHA512 $i; done
-#或者
+# or
 gpg --print-md SHA512 apache-inlong-${release_version}-src.tar.gz
-# 如果上传二进制包,则同样需要检查二进制包的sha512哈希
+# If include a binary package, you also need to check the sha512 hash of the binary package
 gpg --print-md SHA512 apache-inlong-server-${release_version}-bin.tar.gz
 gpg --print-md SHA512 apache-inlong-client-${release_version}-bin.tar.gz
-# 或者
+# or
 for i in *.tar.gz.sha512; do echo $i; sha512sum -c $i; done
 ```
 
-### 2.4. 检查源码包的文件内容
-
-  解压缩`apache-inlong-${release_version}-src.tar.gz`,进行如下检查:
+### 2.4. Check the file content of the source package
+Unzip `apache-inlong-${release_version}-src.tar.gz` and check as follows:
+- [ ] DISCLAIMER-WIP file exists and the content is correct.
+- [ ] LICENSE and NOTICE files are correct for the repository.
+- [ ] All files have ASF license headers if necessary.
+- [ ] The source code can be compiled normally.
+- [ ] The single test can run through.
+- [ ] Building is OK.
 
-  - DISCLAIMER文件是否存在及内容是否正确
-  - LICENSE and NOTICE文件是否存在及内容是否正确
-  - 所有文件是否带有ASF License头
-  - 源码是否能够正常编译
-  - 单测是否能够跑通
-  - ....
+### 2.5 Check the binary package (if the binary package is included)
+  Unzip `apache-inlong-client-${release_version}-src.tar.gz` and `
+  apache-inlong-server-${release_version}-src.tar.gz`, check as follows:
+- [ ] DISCLAIMER-WIP file exists and the content is correct.
+- [ ] LICENSE and NOTICE files are correct for the repository.
+- [ ] The deployment can be successful
+- [ ] Deploy a test environment to verify whether production and consumption can run normally.
+- [ ] Verify what you think might go wrong.
 
-### 2.5 检查二进制包(如果上传了二进制包)
-  解压缩`apache-inlong-client-${release_version}-src.tar.gz`和`
-  apache-inlong-server-${release_version}-src.tar.gz`,进行如下检查:
-  - DISCLAIMER文件是否存在及内容是否正确
-  - LICENSE and NOTICE文件是否存在及内容是否正确
-  - 能否正常部署成功
-  - 部署测试环境、验证生产消费能否正常运行
-  - 验证你认为可能会出问题的地方
-  - ....
\ No newline at end of file
diff --git a/docs/modules/tubemq/client_partition_assign_introduction.md b/docs/modules/tubemq/client_partition_assign_introduction.md
index 449863b..70beb1b 100644
--- a/docs/modules/tubemq/client_partition_assign_introduction.md
+++ b/docs/modules/tubemq/client_partition_assign_introduction.md
@@ -42,5 +42,10 @@ The interaction between each node is as follows:
 - Consumers regularly report status and partition registration information, so that the Master side can perceive the current partition assign and registration status of each SDK so that the server can obtain the partition allocation information of the entire group;
 - Master provides a query API and supports operation and maintenance to query the partition allocation status of each node in the specified partition allocation consumer group through the API query interface.
 
+## 5 Summary
+At this point, we have completed the introduction of client partition assign and made a detailed example of partition allocation through the client's hash modulus based on the total number of partitions and the total number of clients in the consumer group. There is no restriction on the partition allocation scheme, and you can also use other schemes when you use them,  only need to set the sourceCount value to -1 to turn off the system's default allocation strategy.
+
+In the implementation, the initial plan was to externalize the allocation plan in a callback mode and include the partition allocation thread into the SDK. However, later considering that the client may do a lot of fine processing, encapsulation may limit the use of the business. In contrast, the business only creates one more thread, so the current version does not carry out this encapsulation. The follow-up to see the effect of the implementation, if this is necessary, we will improve it.
+
 ---
 <a href="#top">Back to top</a>
\ No newline at end of file
diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/modules/tubemq/client_partition_assign_introduction.md b/i18n/zh-CN/docusaurus-plugin-content-docs/current/modules/tubemq/client_partition_assign_introduction.md
index a276cfd..160fa49 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/modules/tubemq/client_partition_assign_introduction.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/modules/tubemq/client_partition_assign_introduction.md
@@ -7,7 +7,7 @@ title: 客户端分区分配介绍
 1. 数据消费等待时间过长: 客户端从启动到消费到第一条数据的时间比较长,主要原因在于服务侧是按照固定周期进行消费分区的任务分配,且过程中涉及到客户端对已分配分区的资源释放,客户端在最好的情况下都需要等待一个分配周期(可配置,默认30秒)才能获取到待消费分区,在极端情况下有可能超过几分钟,对业务及时消费到数据不满足;
 2. 分区分配方案不够丰富: 当前服务侧分区分配方案是按照客户端订阅的Topic分区总集合,与这个消费组分区分配时的总客户端个数进行Hash取模的方式进行分配,而业务需要采用特别的分配方案时,服务侧目前分配方案则显得不够友好,不能随业务需要随时变更;
 3. 不支持指定分区消费: 在版本使用过程中业务反馈当前服务侧管控不够灵活,比如客户端需要绑定消费者与分区的消费关系,或者某次启动只想消费其中某几个分区时,当前服务侧消费管控不支持。
-针对这些问题,3.9.1版本上线了新的客户端分区分配管控消费模式,结合分区当前消费滞后情况感知功能,让业务自主控制分区的分配和消费。
+针对这些问题,0.12.0版本上线了新的客户端分区分配管控消费模式,结合分区当前消费滞后情况感知功能,让业务自主控制分区的分配和消费。
 
 ## 2 使用示例
 客户端分区分配基于ClientBalanceConsumer接口类进行定义,一共17个API,相关的使用示例代码参考示例代码[ClientBalanceConsumerExample.java](https://github.com/apache/incubator-inlong/blob/master/inlong-tubemq/tubemq-example/src/main/java/org/apache/inlong/tubemq/example/ClientBalanceConsumerExample.java) 。总的代码实现逻辑如下图示:
@@ -40,5 +40,10 @@ title: 客户端分区分配介绍
 - Consumer定期上报状态及分区注册信息,让Master侧感知各个SDK当前分区分配及注册情况,便于服务端获取整个组的分区分配信息;
 - Master提供查询API,支持运维通过API查询接口查询指定分区分配消费组各节点的分区分配情况。
 
+## 5 总结
+到这里,我们就完成了客户端分区分配的介绍,并且通过客户端按照分区总数以及消费组里客户端总个数进行hash取模方式为例做了分区分配的详细示例。这里并没有限制分区的分配方案,大家在使用的时候也可以采用其他的方案,只需要将sourceCount值设置为-1,即可关闭系统默认的分配策略。
+
+在实现的时候最初计划是将分配方案以回调方式对外并将分区分配的线程包含到SDK内部,但后来考虑到客户端可能会做非常多的精细处理,封装起来可能反而会限制业务的使用,且相比而言只是业务多创建一个线程,因而目前版本没有进行这块封装。后续看实施的效果,如果这块需要,我们再改进。
+
 ---
 <a href="#top">Back to top</a>
\ No newline at end of file