Merge branch 'latest' into pgulutzan-gh-2185

Author: alexandra-mara

.github/workflows/deploy-branch.yml

@@ -13,7 +13,7 @@ jobs:
       S3_ENDPOINT_URL: ${{secrets.S3_ENDPOINT_URL}}
       S3_UPLOAD_PATH: ${{secrets.S3_UPLOAD_PATH}}
       TARANTOOL_UPDATE_KEY: ${{secrets.TARANTOOL_UPDATE_KEY}}
-      TARANTOOL_UPDATE_URL: ${{secrets.TARANTOOL_DEV_UPDATE_URL}}
+      TARANTOOL_UPDATE_URL: ${{secrets.TARANTOOL_DEVELOP_UPDATE_URL}}
     steps:
       - uses: actions/checkout@v2
         with:
@@ -39,7 +39,6 @@ jobs:
       - run: make build-modules
       - run: make json
       - run: make json-ru
-      - run: curl ${{secrets.WAKEUP_URL}} --connect-timeout 300 --retry 3 --retry-delay 30 >> /dev/null
       - run: bash upload_output.sh
 
       - name: update deployment status
@@ -49,4 +48,4 @@ jobs:
           token: ${{secrets.GITHUB_TOKEN}}
           status: ${{job.status}}
           deployment_id: ${{steps.deployment.outputs.deployment_id}}
-          env_url: https://tarantool-develop.herokuapp.com/doc/${{env.BRANCH_NAME}}
+          env_url: ${{secrets.TARANTOOL_HOST}}/doc/${{env.BRANCH_NAME}}

.github/workflows/destroy-deployment-manually.yml

@@ -23,4 +23,4 @@ jobs:
 #          onlyRemoveDeployments: true
 
       - run: |
-          curl -X DELETE -d '{"update_key":"${{secrets.TARANTOOL_UPDATE_KEY}}"}' -H "Content-Type: application/json" ${{secrets.TARANTOOL_DEV_UPDATE_URL}}${{env.DEPLOYMENT_NAME}}/
+          curl -X DELETE -d '{"update_key":"${{secrets.TARANTOOL_UPDATE_KEY}}"}' -H "Content-Type: application/json" ${{secrets.TARANTOOL_DEVELOP_UPDATE_URL}}${{env.DEPLOYMENT_NAME}}/

.github/workflows/destroy-deployment.yml

@@ -17,7 +17,7 @@ jobs:
         run: echo "BRANCH_NAME=${GITHUB_HEAD_REF##*/}" >> $GITHUB_ENV
 
       - run: |
-          curl -X DELETE -d '{"update_key":"${{secrets.TARANTOOL_UPDATE_KEY}}"}' -H "Content-Type: application/json" ${{secrets.TARANTOOL_DEV_UPDATE_URL}}${{env.BRANCH_NAME}}/
+          curl -X DELETE -d '{"update_key":"${{secrets.TARANTOOL_UPDATE_KEY}}"}' -H "Content-Type: application/json" ${{secrets.TARANTOOL_DEVELOP_UPDATE_URL}}${{env.BRANCH_NAME}}/
 
       - name: Remove dev server deployment at branch-${{env.BRANCH_NAME}}
         uses: bobheadxi/deployments@v0.5.2

build_submodules.sh

@@ -58,7 +58,7 @@ CMAKE_DUMMY_WEBUI=true tarantoolctl rocks make
 
 cd "${rst_src}" || exit
 mkdir -p "${rst_dest}"
-find . -iregex '.*\.\(rst\|png\)$' -exec cp -r --parents {} "${rst_dest}" \;
+find . -iregex '.*\.\(rst\|png\|puml\)$' -exec cp -r --parents {} "${rst_dest}" \;
 
 cd "${pot_src}" || exit
 mkdir -p "${pot_dest}"

conf.py

@@ -21,6 +21,7 @@
     'sphinx.ext.ifconfig',
     'sphinx.ext.intersphinx',
     'sphinx.ext.extlinks',
+    'sphinxcontrib.plantuml',
     'ext.custom',
     'ext.LuaDomain',
     'ext.LuaLexer',
@@ -42,6 +43,7 @@
     'doc-issue': ('https://github.com/tarantool/doc/issues/%s', 'doc-'),
 }
 
+plantuml_output_format = 'svg_img'
 imgmath_image_format = 'svg'
 
 primary_domain = 'lua'

doc/book/box/data_model.rst

@@ -39,8 +39,8 @@ To control the behavior of synchronous transactions, there exist global
     box.cfg{replication_synchro_quorum = <number of instances>}
 
 This option tells how many replicas should confirm the receipt of a synchronous
-transaction before it can finish its commit. So far this option accounts all
-replicas, including anonymous. As a usage example, consider this:
+transaction before it is committed. So far, this option accounts for all
+replicas including anonymous ones. As a usage example, consider this:
 
 .. code-block:: lua
 
@@ -71,7 +71,7 @@ instance confirms its receipt and successful appliance. Note that the quorum is
 set to 2, but the transaction was still committed even though there is only one
 replica. This is because the master instance itself also participates in the quorum.
 
-Now if the second instance is down, the first one won't be able to commit any
+Now, if the second instance is down, the first one won't be able to commit any
 synchronous change.
 
 .. code-block:: lua
@@ -116,23 +116,23 @@ When there is more than one synchronous transaction, they all wait for being
 replicated. Moreover, if an asynchronous transaction appears, it will
 also be blocked by the existing synchronous transactions. This behavior is very
 similar to a regular queue of asynchronous transactions because all the transactions
-finish their commits in the same order as they start them.
+are committed in the same order as they make the ``box.commit()`` call.
 So, here comes **the commit rule**:
-transactions always finish their commits in the same order as they start
-them  -- regardless of being synchronous or asynchronous.
+transactions are committed in the same order as they make
+the ``box.commit()`` call—regardless of being synchronous or asynchronous.
 
 If one of the waiting synchronous transactions times out and is rolled back, it
 will first roll back all the newer pending transactions. Again, just like how
 asynchronous transactions are rolled back when WAL write fails.
 So, here comes **the rollback rule:**
-transactions are always rolled back in the order reversed from the commit start
-order -- regardless of being synchronous or asynchronous.
+transactions are always rolled back in the order reversed from the one they
+make the ``box.commit()`` call—regardless of being synchronous or asynchronous.
 
-One more important thing is that if an asynchronous transaction is blocked on
+One more important thing is that if an asynchronous transaction is blocked by
 a synchronous transaction, it does not become synchronous as well.
 This just means it will wait for the synchronous transaction to be committed.
-But once it is done, the asynchronous transaction will finish its commit
-immediately -- it won't wait for being replicated itself.
+But once it is done, the asynchronous transaction will be committed
+immediately—it won't wait for being replicated itself.
 
 --------------------------------------------------------------------------------
 Limitations and known problems
@@ -146,14 +146,15 @@ existing spaces, but since 2.5.2 it can be enabled by
 Synchronous transactions work only for master-slave topology. You can have multiple
 replicas, anonymous replicas, but only one node can make synchronous transactions.
 
-Anonymous replicas participate in the quorum. This will change: it won't be possible
-for a synchronous transaction to gather quorum using anonymous replicas in future.
+Anonymous replicas participate in the quorum.
+However, this will change: it won't be possible
+for a synchronous transaction to gather quorum using anonymous replicas in the future.
 
 --------------------------------------------------------------------------------
 Leader election
 --------------------------------------------------------------------------------
 
-Starting from the version :doc:`2.6.1 </release/2.6.1>`,
+Starting from version :doc:`2.6.1 </release/2.6.1>`,
 Tarantool has the built-in functionality
 managing automated leader election in a replica set. For more information,
 refer to the :ref:`corresponding chapter <repl_leader_elect>`.
@@ -168,5 +169,5 @@ transaction will be committed by the new master. Your application logic should b
 ready for that.
 
 Synchronous transactions are better to use with full mesh. Then the replicas can
-talk to each other in case of the master node's death, and still confirm some
+talk to each other in case of the master node's death and still confirm some
 pending transactions.

doc/book/replication/repl_sync.rst

@@ -1,11 +1,10 @@
 .. _documentation_guidelines:
 
--------------------------------------------------------------------------------
-                        Documentation guidelines
--------------------------------------------------------------------------------
+Documentation & Localization guidelines
+=======================================
 
 These guidelines aim to help the team and external contributors
-write, publish, and collaborate on the Tarantool documentation.
+write, translate, publish, and collaborate on the Tarantool documentation.
 
 The guidelines are a work in progress, and we welcome all contributions.
 
@@ -14,6 +13,7 @@ The guidelines are a work in progress, and we welcome all contributions.
     :caption: Contents:
 
     docs/style
+    docs/localization
     docs/terms
     docs/markup
     docs/examples

doc/contributing/docs.rst

@@ -0,0 +1,14 @@
+Localization
+============
+
+This section covers the specifics of localizing Tarantool into Russian.
+If you are translating Tarantool docs into Russian,
+be sure to check out our translation guidelines.
+
+..  toctree::
+    :maxdepth: 2
+    :caption: Contents:
+
+    localization/locstate
+    localization/glossaries
+    localization/guide

doc/contributing/docs/localization.rst

@@ -0,0 +1,10 @@
+Term [en];Term [ru];Description [en];Description [ru]
+;приложение на Tarantool Cartridge;;Если без предлога, то теряется  смысл: читается так, как будто Tarantool Cartridge — это название приложения. А это не так. 
+Tarantool Cartridge application;Tarantool Cartridge — это фреймворк;;" на базе которого можно разработать свое приложение."""
+Cartridge;Cartridge;;
+production environment;производственная среда;Production environment is a term used mostly by developers to describe the setting where software and other products are actually put into operation for their intended uses by end users.;
+failover;восстановление после сбоев;In computing and related technologies such as networking, failover is switching to a redundant or standby computer server, system, hardware component or network upon the failure or abnormal termination of the previously active application, server, system, hardware component, or network.;
+replicaset;набор реплик;;
+directory;директория;;
+bucket;сегмент;;
+check;выберите, выбрать;To select a checkbox;