⬆️ release/v1.7.13 (#191)

* ⬆️ release/v1.7.13 Signed-off-by: Kosuke Morimoto <ksk@vdaas.org> * 🤖 auto update stage ⬆️ Signed-off-by: vdaas-ci <ci@vdaas.org> --------- Signed-off-by: Kosuke Morimoto <ksk@vdaas.org> Signed-off-by: vdaas-ci <ci@vdaas.org> Co-authored-by: vdaas-ci <ci@vdaas.org>
vdaas · Aug 8, 2024 · 26b9de9 · 26b9de9
1 parent 363c216
commit 26b9de9
Show file tree

Hide file tree

Showing 57 changed files with 1,462 additions and 497 deletions.
diff --git a/VERSIONS/GO_VERSION b/VERSIONS/GO_VERSION
@@ -1 +1 @@
-1.22.3
+1.22.6
diff --git a/VERSIONS/VALD_LATEST_VERSION b/VERSIONS/VALD_LATEST_VERSION
@@ -1 +1 @@
-1.7.12
+1.7.13
diff --git a/content/docs/api/build_proto.md b/content/docs/api/build_proto.md
@@ -1,6 +1,6 @@
 ---
 title: "Build_proto_api"
-date: 2024-04-26T11:42:22+09:00
+date: 2024-08-08T00:23:48+09:00
 draft: false
 weight: 1100
 description: How to build gRPC proto files for calling API to your Vald cluster
@@ -238,9 +238,9 @@ There are many tools for building proto in Rust, we use [tonic](https://github.c
         }
         ```
 
-    1.  `src/clinet.rs`
+    1.  `src/client.rs`
 
-        There are 4 steps in `src/clinet.rs`:
+        There are 4 steps in `src/client.rs`:
 
         1. Load dataset
         1. Insert vector to Vald cluster

diff --git a/content/docs/api/filter-gateway.md b/content/docs/api/filter-gateway.md
@@ -1,6 +1,6 @@
 ---
 title: "Filter Gateway_api"
-date: 2024-05-21T15:09:37+09:00
+date: 2024-08-08T00:23:48+09:00
 draft: false
 weight: 800
 description: How to use CRUD API with filter gateway
@@ -13,7 +13,7 @@ menu:
 
 ## Overview
 
-Filter Servie is responsible for providing insert, update, upsert and search interface for `Vald Filter Gateway`.
+Filter Server is responsible for providing insert, update, upsert and search interface for `Vald Filter Gateway`.
 
 Vald Filter Gateway forward user request to user-defined ingress/egress filter components allowing user to run custom logic.
 

diff --git a/content/docs/api/flush.md b/content/docs/api/flush.md
@@ -1,6 +1,6 @@
 ---
 title: "Flush_api"
-date: 2024-04-26T11:42:25+09:00
+date: 2024-08-08T00:23:48+09:00
 draft: true
 weight: 600
 description: Remove all indexes from the Vald cluster
@@ -42,7 +42,6 @@ Flush RPC is the method to remove all vectors.
 
     empty
 
-
 ### Output
 
 - the scheme of `payload.v1.Info.Index.Count`
@@ -58,14 +57,14 @@ Flush RPC is the method to remove all vectors.
   }
   ```
 
-   Object.Info_Index_Count
+  Object.Info_Index_Count
 
-    | field       | type   | label | desc.                                                                      |
-    | :---------: |:------ | :---- | :------------------------------------------------------------------------- |
-    | stored      | uint32 |       | count of indices.                                                          | 
-    | uncommitted | uint32 |       | count of uncommitted indices.                                              |
-    | indexing    |  bool  |       | the state indicating whether `vald-agent` pods is present in the indexing. |
-    | saving      |  bool  |       | the state indicating whether `vald-agent` pods is present in the saving.   |
+  |    field    | type   | label | desc.                                                                      |
+  | :---------: | :----- | :---- | :------------------------------------------------------------------------- |
+  |   stored    | uint32 |       | count of indices.                                                          |
+  | uncommitted | uint32 |       | count of uncommitted indices.                                              |
+  |  indexing   | bool   |       | the state indicating whether `vald-agent` pods is present in the indexing. |
+  |   saving    | bool   |       | the state indicating whether `vald-agent` pods is present in the saving.   |
 
 ### Status Code
 

diff --git a/content/docs/api/remove.md b/content/docs/api/remove.md
@@ -1,6 +1,6 @@
 ---
 title: "Remove_api"
-date: 2024-05-21T15:09:37+09:00
+date: 2024-08-08T00:23:48+09:00
 draft: false
 weight: 500
 description: Remove indexes from the Vald cluster
@@ -171,10 +171,10 @@ RemoveByTimestamp RPC is the method to remove vectors based on timestamp.
 
   - Remove.Timestamp
 
-    |   field   | type                      | label | required | description                                       |
-    | :-------: | :------------------------ | :---- | :------: | :------------------------------------------------ |
-    | timestamp | int64                     |       |    \*    | The timestamp.                                    |
-    | operator  | Remove.Timestamp.Operator |       |          | The conditionl operator. (default value is `Eq`). |
+    |   field   | type                      | label | required | description                                        |
+    | :-------: | :------------------------ | :---- | :------: | :------------------------------------------------- |
+    | timestamp | int64                     |       |    \*    | The timestamp.                                     |
+    | operator  | Remove.Timestamp.Operator |       |          | The conditional operator. (default value is `Eq`). |
 
   - Remove.Timestamp.Operator
 

diff --git a/content/docs/contributing/coding-style.md b/content/docs/contributing/coding-style.md
@@ -1,6 +1,6 @@
 ---
 title: "Coding Style_contributing"
-date: 2024-01-10T18:16:39+09:00
+date: 2024-08-08T00:23:46+09:00
 draft: false
 weight: 300
 description: Coding style for Vald project
@@ -25,7 +25,7 @@ Please also read the [Contribution guideline](/docs/contributing/contributing-gu
 Code formatting and naming conventions affect coding readability and maintainability.
 Every developer has a different coding style.
 Luckily Go provides tools to format source code and check for potential issues in the source code.
-We recommend using [golines](https://github.com/segmentio/golines), [gofumpt](https://github.com/mvdan/gofumpt), and [goimports](https://github.com/golang/tools/tree/master/cmd/goimports) to format the source code in Vald and [golangci-lint](https://github.com/golangci/golangci-lint) with the `--enable-all` option.
+We recommend using [golines](https://github.com/segmentio/golines), [gofumpt](https://github.com/mvdan/gofumpt), and [goimports](https://github.com/golang/tools/tree/master/cmd/goimports) and [crlfmt](https://github.com/cockroachdb/crlfmt) to format the source code in Vald and [golangci-lint](https://github.com/golangci/golangci-lint) with the `--enable-all` option.
 We suggest everyone install the plugin for your editor to format the code once you edit the code automatically and use `make format/go` command if you want to format the source code manually.
 
 But having tools to format source code does not mean you do not need to care about the formatting of the code, for example:
@@ -102,7 +102,7 @@ Here are the naming conventions of the package:
 
   ```go
   // bad
-  package encodebase64
+  package encode
 
   // good
   package base64 // inside the encoding/base64 folder
@@ -284,7 +284,7 @@ The variable and the constant should be named as:
 
   ```go
   // bad
-  yamlprocessor := new(something)
+  yamlProcessor := new(something)
 
   // good
   yamlProcessor := new(something)
@@ -326,7 +326,7 @@ In this section, rules also apply to the `function` (without receiver). The meth
 
   ```go
   // bad
-  func (s *something) somemethod() {}
+  func (s *something) someMethod() {}
 
   // bad
   func (s *something) some_method() {}
@@ -340,7 +340,7 @@ In this section, rules also apply to the `function` (without receiver). The meth
 
   ```go
   // bad
-  func (s *something) genereateRandomNumber() int {}
+  func (s *something) generateRandomNumber() int {}
 
   // good
   func (s *something) genRandNum() int {}
@@ -886,7 +886,7 @@ tests := []test {
 
 for _, tc := range tests {
     test := tc
-    t.Run(test.name, func(tt *tesint.T) {
+    t.Run(test.name, func(tt *testing.T) {
         checkFunc = defaultCheckFunc
         if test.checkFunc != nil {
             checkFunc = test.checkFunc
@@ -1257,7 +1257,7 @@ In Vald, we can apply it to the different helper functions like `beforeFunc()` o
 ```go
 type test struct {
     ...
-    beforeFunc func(*testing.T) // helper function to initialze testing
+    beforeFunc func(*testing.T) // helper function to initialize testing
     afterFunc  func(*testing.T) // helper function to cleanup
 }
 
@@ -1329,7 +1329,7 @@ For example, we decided to mock the following implementation `Encoder`.
 package json
 
 type Encoder interface {
-    Encode(interface{}) ([]byte, error)
+    Encode(any) ([]byte, error)
 }
 ```
 
@@ -1338,7 +1338,7 @@ type encoder struct {
     encoder json.Encoder
 }
 
-func (e *encoder) Encode(obj interface{}) ([]byte, error) {
+func (e *encoder) Encode(obj any) ([]byte, error) {
     return e.encoder.Encode(obj)
 }
 ```
@@ -1349,10 +1349,10 @@ The following is an example of mock implementation:
 package json
 
 type MockEncoder struct {
-    EncoderFunc func(interface{}) ([]byte, error)
+    EncoderFunc func(any) ([]byte, error)
 }
 
-func (m *MockEncoder) Encode(obj interface{}) ([]byte, error) {
+func (m *MockEncoder) Encode(obj any) ([]byte, error) {
     return m.EncodeFunc(obj)
 }
 ```
@@ -1365,7 +1365,7 @@ tests := []test {
         name: "returns (byte{}, nil) when encode success"
         fields: fields {
             encoding: &json.MockEncoder {
-                EncoderFunc: func(interface{}) ([]byte, error) {
+                EncoderFunc: func(any) ([]byte, error) {
                     return []byte{}, nil
                 },
             },

diff --git a/content/docs/contributing/development.md b/content/docs/contributing/development.md
@@ -1,6 +1,6 @@
 ---
 title: "Development_contributing"
-date: 2024-01-10T18:16:39+09:00
+date: 2024-08-08T00:23:46+09:00
 draft: false
 weight: 200
 description: Basic development guide for the Vald project
@@ -36,7 +36,7 @@ This is the easiest way to start developing `Vald`. You can just open our [devco
 We don't officially have a setup documentation for now, but you can take a look at the [`Dockerfile`](https://github.com/vdaas/vald/blob/main/dockers/dev/Dockerfile).
 That's everything you need to build and test `Vald`, so you can use it as a reference.
 
-> If you would like to use the `Dockerfile` directlly, please note that `docker-in-docker` environment is required to run our E2E tests.
+> If you would like to use the `Dockerfile` directly, please note that `docker-in-docker` environment is required to run our E2E tests.
 > In devcontainer, [`VS Code` handles it for us](https://github.com/devcontainers/features/tree/main/src/docker-in-docker).
 
 ## Run tests

diff --git a/content/docs/contributing/reviewer-guideline.md b/content/docs/contributing/reviewer-guideline.md
@@ -0,0 +1,92 @@
+---
+title: "Reviewer Guideline_contributing"
+date: 2024-08-08T00:23:46+09:00
+draft: false
+weight: 0
+description: ""
+menu:
+  contributing:
+    parent: Contributing
+---
+
+# Guideline for the Pull Request reviewers
+
+This document serves as a guideline for those reviewing Pull Requests.
+
+This guideline is intended for internal developers. A separate guideline for external contributors is planned.
+
+## Purpose
+
+The purpose of this guideline is to clarify what reviewers should be aware of and to optimize communication, thereby facilitating efficient development of Vald.
+
+## Preparation
+
+This guideline assumes that the content of the Pull Request is appropriate.
+
+Consider splitting the Pull Request if the changes are extensive, have multiple intentions, or if the tests are insufficient. This makes it easier to review.
+
+Regarding the amount of change, opinions may vary, but in this project, we aim to keep the implementation of logic under 1000 lines, excluding automatically generated code such as Protocol Buffers.
+
+## Review request
+
+In this project, merging a Pull Request requires approval from two people. If you want a specific person to review, assign them explicitly; otherwise, assign random people.
+
+### Request notification
+
+People may notice requests through different means, but in this project, we prioritize the following methods of communication:
+
+1. If you are available to communicate with us via online meeting systems like Zoom, please feel free to notify us directly.
+1. Send a mention in some way. For example, we use [Slack](https://join.slack.com/t/vald-community/shared_invite/zt-db2ky9o4-R_9p2sVp8xRwztVa8gfnPA) and we have [X account](https://twitter.com/vdaas_vald).
+1. Email from GitHub is automatically sent when someone is assigned.
+
+If the reviewer does not notice the request, we follow the same priority for re-notifying.
+
+#### When Requested for Review
+
+Unless there are high-priority issues, you are in a meeting, or deeply focused on development, start the review immediately.
+
+## Approve condition
+
+- The content of the Pull Request is understood.
+- The content can be understood at a glance.
+  - If it cannot be understood at a glance, request additional comments.
+- There are no deficiencies in the test cases.
+- The quality is suitable for release.
+  - Compatibility
+  - Security
+  - Performance
+
+Regarding quality, while there is always room for improvement, if the quality is sufficient for release, it is acceptable to approve. If there is potential for improvement, suggest it in the comments, and let the implementer decide whether to address it in the same Pull Request or a separate one.
+
+### What Reviewers Should Do
+
+- If the title or description is unclear, ask questions before reviewing the code.
+- If any part of the code is not understood after a brief review, ask for clarification or additional comments instead of trying to understand it yourself.
+- Verify if the test cases are sufficient.
+- Approve immediately if there are no comments.
+- If interrupted, respond even if the review is incomplete.
+- Ignore other reviewers' comments.
+
+### What Reviewers Should Not Do
+
+- Try to decipher something that is not immediately understandable.
+- Close the browser or tab or start something else if it is not understood.
+- Attempt to verify the implementation in detail.
+
+### Communication Methods
+
+All communications do not need to be completed on GitHub. Using Slack or Zoom can make the review process more efficient.
+
+The following criteria often determine the choice of communication tool:
+
+- On GitHub Mainly used for specific questions or comments about the code. If the exchange is unsuitable for comments, use Slack or Zoom.
+- On Slack, used for brief exchanges. If the discussion is likely to be lengthy or complex, switch to Zoom.
+- On Zoom Used when more complex communication is necessary.
+
+Regardless of where communication takes place, ensure that the results are documented on GitHub or in the code as a record of the communication.
+
+## Effect measurement
+
+Once a month, a report is created at [Vald Issues](https://github.com/vdaas/vald/issues).
+
+This report includes the time taken from when a Pull Request is opened to when it is merged and a summary of this data. Regularly reflect on this information.
diff --git a/content/docs/contributing/unit-test-guideline.md b/content/docs/contributing/unit-test-guideline.md
@@ -1,6 +1,6 @@
 ---
 title: "Unit Test Guideline_contributing"
-date: 2024-01-10T18:16:40+09:00
+date: 2024-08-08T00:23:46+09:00
 draft: false
 weight: 400
 description: Unit test guideline for Vald project
@@ -99,7 +99,7 @@ It is not only a single input, but also multi inputs.
 
 If a function or method accepts multiple inputs, we should try to create test cases to cover all the inputs.
 
-(Note: The below `calcSum()` is diffrent function from `calsSum(val ...int32)` which we mention before.)
+(Note: The below `calcSum()` is different function from `calcSum(val ...int32)` which we mention before.)
 
 ```go
 func calcAverageDiff(val1 []int32, val2 []int32) (diff float64) {
@@ -191,7 +191,7 @@ And, you may also create unit tests based on robust boundary tests or equivalenc
 
 But, we have to take care the Vald is developed using Go.
 As you know as Go has many coding features as other languages.
-One of the features is that Go will convert a single value to a slice value when the Function or Method receives a variadic argument (e.g., `...[]int`, `...[]string`, `...interface{}`, or etc.) as the input.
+One of the features is that Go will convert a single value to a slice value when the Function or Method receives a variadic argument (e.g., `...[]int`, `...[]string`, `...any`, or etc.) as the input.
 
 And we apply the table-driven test for running unit tests.
 For example, when we create the unit test of `func getMeta(...[]int)`, the test code will be more complex than other functions' tests which don't use variadic argument as the input, if we create the test for all input patterns.
@@ -200,15 +200,15 @@ So, we define the basic unit case slightly different from [the basic test case](
 This change is very clear and you can apply it easily.
 Our basic test case depends on the type of two variadic arguments.
 
-1. When input is `...interface{}`
-   - We have to write all test cases which satisfy `...interface{}` as same as a [basic test case](#Basic). For example, `val = 1`, `val = "input"`, `val = []float64{2020.12}` and so on.
-1. When input is not `...interface{}` but `...[]int`, `...[]string` or etc.
+1. When input is `...any`
+   - We have to write all test cases which satisfy `...any` as same as a [basic test case](#Basic). For example, `val = 1`, `val = "input"`, `val = []float64{2020.12}` and so on.
+1. When input is not `...any` but `...[]int`, `...[]string` or etc.
    - We have to create only slice pattern test cases, which is the same as not creating test cases with a single value.
    - We should test with boundary cases, for example, we should test with `val = []int{math.MaxInt64()}` when the input value is `...[]int`.
 
 Summarize Vald unit test guideline:
 
-- Apply basic test case, but take care of input variable pattern, in particular, the variadic argument (`...interface{}` or not)
+- Apply basic test case, but take care of input variable pattern, in particular, the variadic argument (`...any` or not)
 - Apply robust boundary tests, including edge cases (e.g., `math.MaxInt64()`)
 - Apply equivalence class testing when needed.
 

diff --git a/content/docs/overview/architecture.md b/content/docs/overview/architecture.md
@@ -1,6 +1,6 @@
 ---
 title: "Architecture_overview"
-date: 2024-01-10T18:16:40+09:00
+date: 2024-08-08T00:23:48+09:00
 draft: false
 weight: 200
 description: High-Level architecture design and overview of each component
@@ -58,7 +58,7 @@ Here are the concepts of Vald.
 
 - Distributed vector spaces
 
-  All the vector data and indexes are distributed to Vald Agents in the Vald cluster. Whenever you search a vector in Vald cluster, all Vald agents can process parallelly and merge the result by Vald LB Gateway.
+  All the vector data and indexes are distributed to Vald Agents in the Vald cluster. Whenever you search a vector in Vald cluster, all Vald agents can process parallel and merge the result by Vald LB Gateway.
 
 - Kubernetes based