Merge 'Fix typos' from Dmitriy Rokhfeld (TripleChecker)

Hey, our tool caught a few typos in your repository.

Also, here is your site's error report: https://triplechecker.com/s/Dza11H/scylladb.com

Hope it's helpful!

Closes scylladb/scylladb#22787

* github.com:scylladb/scylladb:
  Fix typos
  Fix typos

CONTRIBUTING.md

@@ -12,7 +12,7 @@ Please use the [issue tracker](https://github.com/scylladb/scylla/issues/) to re
 
 ## Contributing code to Scylla
 
-Before you can contribute code to Scylla for the first time, you should sign the [Contributor License Agreement](https://www.scylladb.com/open-source/contributor-agreement/) and send the signed form cla@scylladb.com. You can then submit your changes as patches to the to the [scylladb-dev mailing list](https://groups.google.com/forum/#!forum/scylladb-dev) or as a pull request to the [Scylla project on github](https://github.com/scylladb/scylla).
+Before you can contribute code to Scylla for the first time, you should sign the [Contributor License Agreement](https://www.scylladb.com/open-source/contributor-agreement/) and send the signed form cla@scylladb.com. You can then submit your changes as patches to the [scylladb-dev mailing list](https://groups.google.com/forum/#!forum/scylladb-dev) or as a pull request to the [Scylla project on github](https://github.com/scylladb/scylla).
 If you need help formatting or sending patches, [check out these instructions](https://github.com/scylladb/scylla/wiki/Formatting-and-sending-patches).
 
 The Scylla C++ source code uses the [Seastar coding style](https://github.com/scylladb/seastar/blob/master/coding-style.md) so please adhere to that in your patches. Note that Scylla code is written with `using namespace seastar`, so should not explicitly add the `seastar::` prefix to Seastar symbols. You will usually not need to add `using namespace seastar` to new source files, because most Scylla header files have `#include "seastarx.hh"`, which does this.

LICENSE-ScyllaDB-Source-Available.md

@@ -49,7 +49,7 @@ The terms "**You**" or "**Licensee**" refer to any individual accessing or using
 
 * **Ownership:** Licensor retains sole and exclusive ownership of all rights, interests and title in the Software and any scripts, processes, techniques, methodologies, inventions, know-how, concepts, formatting, arrangements, visual attributes, ideas, database rights, copyrights, patents, trade secrets, and other intellectual property related thereto, and all derivatives, enhancements, modifications and improvements thereof. Except for the limited license rights granted herein, Licensee has no rights in or to the Software and/ or Licensor’s trademarks, logo, or branding and You acknowledge that such Software, trademarks, logo, or branding is the sole property of Licensor.
 * **Feedback:** Licensee is not required to provide any suggestions, enhancement requests, recommendations or other feedback regarding the Software ("Feedback").  If, notwithstanding this policy, Licensee submits Feedback, Licensee understands and acknowledges that such Feedback is not submitted in confidence and Licensor assumes no obligation, expressed or implied, by considering it.  All right in any trademark or logo of Licensor or its affiliates and You shall make no claim of right to the Software or any part thereof to be supplied by Licensor hereunder and acknowledges that as between Licensor and You, such Software is the sole proprietary, title and interest in and to Licensor.such Feedback shall be assigned to, and shall become the sole and exclusive property of, Licensor upon its creation.
-* Except for the rights expressly granted to You under this Agreement, You are not granted any other licenses or rights in the Software or otherwise. This Agreement constitutes the entire agreement between the You and the Licensor with respect to the subject matter hereof and supersedes all prior or contemporaneous communications, representations, or agreements, whether oral or written.
+* Except for the rights expressly granted to You under this Agreement, You are not granted any other licenses or rights in the Software or otherwise. This Agreement constitutes the entire agreement between You and the Licensor with respect to the subject matter hereof and supersedes all prior or contemporaneous communications, representations, or agreements, whether oral or written.
 * **Third-Party Software:** Customer acknowledges that the Software may contain open and closed source components (“OSS Components”) that are governed separately by certain licenses, in each case as further provided by Company upon request. Any applicable OSS Component license is solely between Licensee and the applicable licensor of the OSS Component and Licensee shall comply with the applicable OSS Component license.
 * If any provision of this Agreement is held to be invalid or unenforceable, such provision shall be struck and the remaining provisions shall remain in full force and effect.
 

docs/alternator/alternator.md

@@ -89,7 +89,7 @@ With Alternator enabled on port 8000 (for example), every Scylla node
 listens for DynamoDB API requests on this port. These requests, in
 JSON format over HTTP, are parsed and result in calls to internal Scylla
 C++ functions - there is no CQL generation or parsing involved.
-In Scylla terminology, the node receiving the request acts as the the
+In Scylla terminology, the node receiving the request acts as the
 *coordinator*, and often passes the request on to one or more other nodes -
 *replicas* which hold copies of the requested data.
 

docs/alternator/compatibility.md

@@ -34,7 +34,7 @@ Instructions for doing this can be found in:
 ## Write isolation policies
 
 Scylla was designed to optimize the performance of pure write operations -
-writes which do not need to read the the previous value of the item.
+writes which do not need to read the previous value of the item.
 In CQL, writes which do need the previous value of the item must explicitly
 use the slower LWT ("LightWeight Transaction") feature to be correctly
 isolated from each other. It is not allowed to mix LWT and non-LWT writes
@@ -89,12 +89,12 @@ one or more of the following:
 3. Consider using the `always_use_lwt` write isolation policy.
    It is slower, but has better guarantees.
 
-Another guarantee that that `always_use_lwt` can make and other write
+Another guarantee that `always_use_lwt` can make and other write
 isolation modes do not is that writes to the same item are _serialized_:
 Even if the two write are sent at exactly the same time to two different
 nodes, the result will appear as if one write happened first, and then
 the other. But in other modes (with non-LWT writes), two writes can get
-exactly the same microsecond-resolution timestamp, the the result may be
+exactly the same microsecond-resolution timestamp, the result may be
 a mixture of both writes - some attributes from one and some from the
 other - instead of being just one or the other.
 

docs/dev/cdc.md

@@ -93,7 +93,7 @@ Then `tok` is mapped into
 ```
 _entries[i][p.shard_of(tok, _entries[i].streams.size(), _entries[i].sharding_ignore_msb)]
 ```
-The motivation for this is the following: the token ranges defined by `topology_description` using `token_range_end`s are a refinement of vnodes in the token ring at the time when this generation operates (i.e. each range defined by this generation is wholly contained in a single vnode). The streams in vector `_entries[i].streams` have their tokens in the `i`th range. Therefore we map each token `tok` to a stream whose token falls into the the same vnode as `tok`. Hence, when we perform a base table write, the corresponding CDC log write will fall into the same vnode, thus it will have the same set of replicas as the base write. We call this property __colocation__ of base and log writes.
+The motivation for this is the following: the token ranges defined by `topology_description` using `token_range_end`s are a refinement of vnodes in the token ring at the time when this generation operates (i.e. each range defined by this generation is wholly contained in a single vnode). The streams in vector `_entries[i].streams` have their tokens in the `i`th range. Therefore we map each token `tok` to a stream whose token falls into the same vnode as `tok`. Hence, when we perform a base table write, the corresponding CDC log write will fall into the same vnode, thus it will have the same set of replicas as the base write. We call this property __colocation__ of base and log writes.
 
 To achieve the above it would be enough if `_entries[i].streams` was a single stream, not a vector of streams. But we went further and aim to achieve not only colocation of replicas, but also colocation of shards (not necessarily at all replicas, but a subset of them at least).
 

docs/dev/code-coverage.md

@@ -50,7 +50,7 @@ Examples:
 
 ## Advanced And Manual Workflows
 Once built with code coverage instrumentation, all test executables and scylla executable are going
-to dump a a profile upon graceful shutdown / clean exit. However, in order to produce a coverage report some extra processing is needed.
+to dump a profile upon graceful shutdown / clean exit. However, in order to produce a coverage report some extra processing is needed.
 For reference of how to process the profile dumps using the llvm toolchain, refer to: https://clang.llvm.org/docs/SourceBasedCodeCoverage.html
 
 HINT: It is recommended to run with LLVM_PROFILE_FILE set in the environment so the profiles will be dumped to a known location (https://clang.llvm.org/docs/SourceBasedCodeCoverage.html#running-the-instrumented-program)
@@ -74,7 +74,7 @@ HINT: It is recommended to run with LLVM_PROFILE_FILE set in the environment so
 
    #### 3. Producing A Report From Lcov trace files:
    For textual reports:
-   1. `lcov --summary profiles/85e5e08c67bd9bd74c2caeb98aca2a45360cf25a.info` for a summary of the the coverage rates:
+   1. `lcov --summary profiles/85e5e08c67bd9bd74c2caeb98aca2a45360cf25a.info` for a summary of the coverage rates:
    ```
    Reading tracefile profiles/85e5e08c67bd9bd74c2caeb98aca2a45360cf25a.info
    Summary coverage rate:

docs/dev/compilation-time-analysis.md

@@ -3,7 +3,7 @@ our issue #1 - https://github.com/scylladb/scylladb/issues/1 - is about it.
 To reduce Scylla's compilation time, it's important to understand what is
 causing it.
 
-In the old days of of C compilers, the compilation time was mostly
+In the old days of C compilers, the compilation time was mostly
 proportional to the amount of source code. The only way to reduce compilation
 time without deleting source code was to reduce the amount of unnecessary
 header-file inclusion. However, in modern template-heavy C++ code, such
@@ -207,7 +207,7 @@ that included database.hh, only 46 included it directly - others included
 it through `wasm.hh` and `query_processor.hh` - are those indirect
 includes necessary?
 
-It's worth noting that the the cost of 1086 seconds is an **overestimation**.
+It's worth noting that the cost of 1086 seconds is an **overestimation**.
 In practice, deleting this header file will not reduce 1086 seconds of the
 compilation time. The reason is that database.hh probably includes other
 headers and instantiates templates which get "billed" to it because this

docs/dev/debugging.md

@@ -346,7 +346,7 @@ The form can also be used to decode backtraces generated
 by the corresponding scylla binary.
 
 **NOTE**: Use the normal relocatable package, usually called
-`scylla-package.tar.gz`, not not the debuginfo one usually called
+`scylla-package.tar.gz`, not the debuginfo one usually called
 `scylla-debug-package.tar.gz`.
 
 Build-id:s for all official releases are listed on

docs/dev/isolation.md

@@ -23,7 +23,7 @@ The groups currently defined are:
 | gossip                                       | 1000
 | streaming (a.k.a maintenance)                | 200
 
-TODO: explain the purpose each of each of these scheduling groups, and what they are used for. E.g., "streaming" is also called maintenance and used also used for repair. memtable is used for memtable flushes (?). default is used for gossip, etc.
+TODO: explain the purpose of each of these scheduling groups, and what they are used for. E.g., "streaming" is also called maintenance and used also used for repair. memtable is used for memtable flushes (?). default is used for gossip, etc.
 
 The "Default shares" is the initial number of shares given to each scheduling group. They can be later modified by controllers, which aim to discover when a certain component needs to run faster because it is not keeping up - or run slower because it is finishing more quickly than it needs and causing performance to fluctuate. See the "Controllers" section below.
 

docs/dev/metrics.md

@@ -3,7 +3,7 @@ Scylla exposes dozens of different metrics which are valuable for
 understanding the performance of a node, and for diagnosing performance
 problems when those occur. Among other things, you can see counts of requests,
 activity of disks, cpus and network, memory usage of different types,
-activity in different individual tables, and many many more metrics.
+activity in different individual tables, and many more metrics.
 
 Scylla's metrics are implemented using Seastar's metrics infrastructure.
 Scylla's code updates metrics continuously in memory variables, and then
@@ -188,7 +188,7 @@ this using the Prometheus time-series database.
 Prometheus is installed on a separate monitoring node (which we shall call
 below "monitornode"). It connects to several Scylla nodes, and saves their
 metrics into a time-series database. Prometheus then allows querying,
-analyzing, and and graphing this data, via a Web interface at:
+analyzing, and graphing this data, via a Web interface at:
 
     http://monitornode:9090/
 

docs/dev/protocol-extensions.md

@@ -56,7 +56,7 @@ The keys and values are:
     is connected to (for example, `3`).
   - `SCYLLA_NR_SHARDS` is an integer containing the number of shards on this
     node (for example, `12`). All shard numbers are smaller than this number.
-  - `SCYLLA_PARTITIONER` is a the fully-qualified name of the partitioner in use (i.e.
+  - `SCYLLA_PARTITIONER` is the fully-qualified name of the partitioner in use (i.e.
     `org.apache.cassandra.partitioners.Murmur3Partitioner`).
   - `SCYLLA_SHARDING_ALGORITHM` is the name of an algorithm used to select how
     partitions are mapped into shards (described below)

docs/dev/protocols.md

@@ -25,7 +25,7 @@ https://www.scylladb.com/2020/05/21/dissecting-scylla-packets-with-wireshark/
 
 ## Internal communication
 
-All inter-node communiction - communication between the Scylla nodes
+All inter-node communication - communication between the Scylla nodes
 themselves - happen over one protocol and one TCP port - by default port 7000
 (unencrypted) or 7001 (encrypted). These are the same TCP ports used by
 Cassandra for this purpose, but Scylla's internal protocol is completely

docs/dev/redis.md

@@ -51,7 +51,7 @@ time. When using simple Redis client,  the server address is needed, and
 all the requests are sent to this address, and the requests only send to
 the single Redis server.
 
-In Scylla terminology, the node receiving the request acts as the the
+In Scylla terminology, the node receiving the request acts as the
 coordinator, and often passes the request on to one or more other nodes,
 which hold copies of the requested data.  Any node of Scylla cluster can
 process the request correctly. In other words, Client can send request to
@@ -91,7 +91,7 @@ name should be created (if not exists) or loaded.
 We known that, Redis allows us to store keys that map to any one of the
 basic data structures. Scylla supports variant type, which allows us to
 define one table to store all kind of these Redis data. For example ,we
-create the table with the schame as follow:
+create the table with the schema as follow:
 
 ```
 CREATE TABLE redis （
@@ -113,7 +113,7 @@ will have more performance cost with bigger data structure.
 > structure is exceeded the server's memory size.
 
 So single table to store all the data structures is not good idea, instead
-of five independent tables are created to hold the the different Redis
+of five independent tables are created to hold the different Redis
 structure types within each column family related Redis database. In other
 words, all of the STRINGs of the Redis will be stored in a table within the
 column family, and all of the LISTs' elements will be stored in anther
@@ -374,7 +374,7 @@ The Redis API in Scylla supports the following subset of the Redis commands.
 | **Connection** | |
 | `ECHO message` | Echo a `message` back to the client. The server returns `message´ as a response. |
 | `PING [message]` | Check connection liveness or measure response time. The server returns `PONG` as a response. |
-| `SELECT index` | Select logical database database for the current connection. |
+| `SELECT index` | Select logical database for the current connection. |
 | **Keys** | |
 | `DEL key [key ...]` | Delete `key` from the database. |
 | `EXISTS key [key..]` | Check if `key` exists in the database. |

docs/dev/row_level_repair.md

@@ -1,6 +1,6 @@
 # Row level repair
 
-## How the the partition level repair works
+## How the partition level repair works
 
 - The repair master decides which ranges to work on.
 - The repair master splits the ranges to sub ranges which contains around 100

docs/dev/service_levels.md

@@ -160,7 +160,7 @@ The response is returned immediately but the actual work might take up to tens o
 
 ### Inspecting current scheduling group of connections
 
-`/service_levels/count_connections` endpoing is a tool to inspect status of all opened CQL connections. It returns a map with connections count per scheduling group, per user:
+`/service_levels/count_connections` endpoint is a tool to inspect status of all opened CQL connections. It returns a map with connections count per scheduling group, per user:
 ```
 {'sl:default': {'cassandra': 3}, 'sl:sl1': {'test_user': 3}}
 ```

docs/dev/testing.md

@@ -189,7 +189,7 @@ A typical debugging journey should start with looking at `test.py.log` in
 to server log and pytest output.
 
 To extend `test.py` logging, you can use the standard 'logging' module API.
-Individual pytests are programmed to not gobble stdout, so you can can also
+Individual pytests are programmed to not gobble stdout, so you can also
 add prints to pytests, and they will end up in the test' log.
 
 For example, imagine `cqlpy/test_null.py` fails. The relevant lines
@@ -275,7 +275,7 @@ operations and can clean up resources, including added
 servers, when tests end.
 `test.py` automatically detects if a cluster can not be shared with a
 subsequent test because it was manipulated with. Today the check
-is quite simple: any cluster that has has nodes added or removed,
+is quite simple: any cluster that has nodes added or removed,
 started or stopped, even if it ended up in the same state
 as it was at the beginning of the test, is considered "dirty".
 Such clusters are not returned to the pool, but destroyed, and

tools/toolchain/README.md

@@ -35,7 +35,7 @@ The above command works as follows:
    container, so the same directory can be reused.
 3. The ":z" flag is necessary on systems with SELinux enabled, and causes a
    special selinux label to be applied to $HOME/.ccache so docker can write
-   it it. While this (rightfully) sounds fishy, note that dbuild already does
+   it. While this (rightfully) sounds fishy, note that dbuild already does
    the same thing to your current directory, where the build output is
    written - the current directory is also mounted with the ":z" flag.