diff --git a/.github/vale/styles/Aiven/capitalization_headings.yml b/.github/vale/styles/Aiven/capitalization_headings.yml index e77482e452..965387a38a 100644 --- a/.github/vale/styles/Aiven/capitalization_headings.yml +++ b/.github/vale/styles/Aiven/capitalization_headings.yml @@ -16,6 +16,7 @@ exceptions: - Apache - AWS Transit Gateway - Auth0 + - Azure - Azure Marketplace - Boot - Business @@ -57,6 +58,8 @@ exceptions: - InnoDB - IPsec - Java + - JMX + - Jolokia - Kafdrop - Kafka - Karapace diff --git a/docs/platform/concepts/service-power-cycle.rst b/docs/platform/concepts/service-power-cycle.rst index 42372ec2a6..a9336e9473 100644 --- a/docs/platform/concepts/service-power-cycle.rst +++ b/docs/platform/concepts/service-power-cycle.rst @@ -3,7 +3,9 @@ Service power cycle Aiven service power off and power on is more than stopping and starting a service on nodes. For better utilisation of resources on Aiven platform, idle resources will be released and only the necessary data will be kept after power off. The impact on the service is different depending on the service type and plan. -.. warning:: Depending on service type and plan, data loss may happen during a service power off, so it is important for users to understand the consequences before powering off a service. +.. Warning:: + + Depending on service type and plan, data loss may happen during a service power off, so it is important for users to understand the consequences before powering off a service. Aiven service power off and power on can be done on `Aiven Console `_ or through :doc:`Aiven CLI `. @@ -14,15 +16,25 @@ Whenever an Aiven service is powered off: * All virtual machine(s) of the service will be **removed** from the public cloud. * The service information and configuration will be stored on Aiven Platform, while service data will be lost if there's no backup available . -* If the service has **time-based** or **PITR (point in time recovery)** backups, they will be kept on Aiven Platform. The backups are listed in the ``Backups`` tab of the service on Aiven Console. Absence of the tab means the service has no backups. For details on backups for different Aiven services on different plans, please refer to :doc:`Backups at Aiven `. -.. warning:: Aiven does `periodic cleanup of powered-off services `_ on services powered off for longer than **180** consecutive days. Notification emails will be sent before actions are taken. -* The message in the **Power Off Confirmation** window will give some hints on the consquence of the power off. Below is an example of powering off an Aiven for Redis service whose data since the latest backup will be lost because the service only has time-based but not PITR backups. +* If the service has **time-based** or **PITR (point in time recovery)** backups, they will be kept on Aiven Platform. The backups are listed in the **Backups** tab of the service on Aiven Console. Absence of the tab means the service has no backups. For details on backups for different Aiven services on different plans, please refer to :doc:`Backups at Aiven `. + +.. Warning:: + + Aiven does `periodic cleanup of powered-off services `_ on services powered off for longer than **180** consecutive days. Notification emails will be sent before actions are taken. + +* The message in the **Power Off Confirmation** window will give some hints on the consequence of the power off. Below is an example of powering off an Aiven for Redis®* service whose data since the latest backup will be lost because the service only has time-based but not PITR backups. + .. image:: /images/platform/power-off-confirmation.png :alt: Power Off Confirmation + * Moreover, under the ``Backups`` tab, hovering the mouse over the help icon (if it's available) can present some details on the content of the backups. This information suggests what can be restored if the service is powered on later. + .. image:: /images/platform/backup-help-info.png :alt: Backup Help Information -.. warning:: For backup enabled Aiven for Apache Kafka® services, topic configuration, schemas and connectors are all backed up, but not the data in topics. Therefore all topic data will be lost on power off. For Kafka services without backups, topic configurations together with all topic data will be lost on power off. + +.. Warning:: + + For backup enabled Aiven for Apache Kafka® services, topic configuration, schemas and connectors are all backed up, but not the data in topics. Therefore all topic data will be lost on power off. For Kafka services without backups, topic configurations together with all topic data will be lost on power off. Power on @@ -33,8 +45,10 @@ When a service is powered on, the following things will happen: * New virtual machine(s) will be created on the specified public cloud for the service. * Service will be started with the stored configuration parameters. * The latest time-based backup that is available will be restored. The restore time depends on the network bandwidth and disk IOPS allocated to the service plan as well as the size of the backup. It could take from minutes to hours. Smaller plans with larger backups take longer time than bigger plans with smaller backups. Restore progress can be checked by Aiven support with Aiven Admin CLI. -* If PITR backup is avilable, the database transaction log (e.g. ``WAL`` for PostgreSQL, ``binlog`` for MySQL) will be replayed to recover the service data to a specific point in time. +* If PITR backup is available, the database transaction log (e.g. ``WAL`` for PostgreSQL®, ``binlog`` for MySQL) will be replayed to recover the service data to a specific point in time. * Service will be ready for serving. -.. warning:: Depending on the service plan, backups have different retention periods. Data will be lost after the retention period. +.. Warning:: + + Depending on the service plan, backups have different retention periods. Data will be lost after the retention period. diff --git a/docs/platform/howto/manage-vpc-peering.rst b/docs/platform/howto/manage-vpc-peering.rst index 7ea21aa467..f7cb57bb35 100644 --- a/docs/platform/howto/manage-vpc-peering.rst +++ b/docs/platform/howto/manage-vpc-peering.rst @@ -14,6 +14,7 @@ To set up VPC peering for your Aiven project: 3. On the right, click **Create VPC** button. .. note:: + You'll need either an **admin** or an **operator** user role to be able to create a VPC. For more information about Aiven project members and roles, refer to :doc:`../concepts/projects_accounts_access`. 4. Enter the IP range that you want to use for the VPC connection. Use an IP range that does not overlap with any networks that you want to connect via VPC peering. For example, if your own networks use the range `10.0.0.0/8`, you could set the range for your Aiven project's VPC to `192.168.0.0/24`. @@ -25,6 +26,7 @@ Once you have created the VPC, Aiven automatically sets it up and updates the st When you create a new service, you can then place it in the VPC. The **VPC** tab in the *Select Service Cloud Region* section lists the available VPC. This also allows you to migrate a service to or from a VPC. .. note:: + Depending on the cloud provider that you selected for the VPC connection, you also have to accept a VPC peering connection request or set up a corresponding VPC peering connection to Aiven. Cloud-specific VPC peering instructions @@ -34,7 +36,7 @@ Cloud-specific VPC peering instructions - :doc:`Set up VPC peering on Google Cloud Platform (GCP) ` - :doc:`Set up VNet (VPC) peering on Microsoft Azure ` -Deploying new services to a VPC +Deploy new services to a VPC ------------------------------- When you create a new service, your peered VPC is available as a new geolocation on the **VPC** tab under *Select Service Cloud Region*. @@ -44,13 +46,13 @@ It might take a few minutes for newly created VPC to appear for service deployme The service nodes use firewall rules to allow only connections from private IP ranges that originate from networks on the other end of VPC peering connections. You can only deploy services to a VPC if they belong to the project where that specific VPC was created. -Deleting an existing VPC and VPC peering +Delete an existing VPC and VPC peering ---------------------------------------- Before deleting an existing VPC from Aiven console, you should move out any active services from that VPC. To delete a VPC, navigate to the Aiven console under the VPC section. You can find the **Delete** button as the last column for each VPC. Once the VPC is deleted, the cloud provider side of the peering connection will go to an inactive or deleted state. -Migrating a public service to a VPC +Migrate a public service to a VPC ----------------------------------- You can migrate any Aiven service to or from a VPC. @@ -70,7 +72,7 @@ You can migrate any Aiven service to or from a VPC. Once you migrate your service to an Aiven project-specific VPC, you can no longer access the service over the public internet. You can only access it from clients that are in a VPC that is peered to the VPC for the Aiven project. -Accessing VPC services from the public internet +Access VPC services from the public internet ----------------------------------------------- When you move your service to a VPC, access from public networks is blocked by default unless you switch on public access, which generates a separate endpoint with a public- prefix that you can use. diff --git a/docs/platform/howto/restrict-access.rst b/docs/platform/howto/restrict-access.rst index c3f57fbc79..83493b007b 100644 --- a/docs/platform/howto/restrict-access.rst +++ b/docs/platform/howto/restrict-access.rst @@ -1,5 +1,5 @@ Restrict network access to your service -======================================= +======================================== It is possible to restrict access to your service to a single IP, and address block, or any combination of both. By default the service is publicly accessible. diff --git a/docs/platform/howto/vnet-peering-azure.rst b/docs/platform/howto/vnet-peering-azure.rst index 855d5b3ab1..c8fa35d4f1 100644 --- a/docs/platform/howto/vnet-peering-azure.rst +++ b/docs/platform/howto/vnet-peering-azure.rst @@ -34,7 +34,7 @@ Preparation Please install the `Azure CLI `__ as well as the :doc:`Aiven CLI ` to follow this guide. -1. Log in with an Azure admin account +1. log in with an Azure admin account ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Using the Azure CLI: @@ -57,7 +57,7 @@ is not needed if there's only one subscription: az account set --subscription   -2. Create application object +2. create application object ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Create an application object in your AD tenant. Using the Azure CLI, @@ -73,7 +73,7 @@ tenant (the tenant the app was created in) has the credentials to authenticate the app. Save the ``appId`` field from the output - this will be referred to as ``$user_app_id`` -3. Create a service principal for your app object +3. create a service principal for your app object ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Create a service principal for the app object you created. The service @@ -90,7 +90,7 @@ output - this will be referred to as ``$user_sp_id`` . Notice that this is different from the ``$user_app_id`` value earlier, which is also shown in the output. -4. Set a password for your app object +4. set a password for your app object ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ :: @@ -100,7 +100,7 @@ shown in the output. Save the ``password`` field from the output - this will be referred to as ``$user_app_secret`` below -5. Find the id properties of your virtual network +5. find the id properties of your virtual network ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This can be found in the Azure portal in "Virtual networks" -> name of @@ -127,7 +127,7 @@ Also grab ``$user_vnet_id`` should have the format ``/subscriptions/$user_subscription_id/resourceGroups/$user_resource_group/providers/Microsoft.Network/virtualNetworks/$user_vnet_name`` -6. Grant your service principal permissions to peer +6. grant your service principal permissions to peer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The service principal created in step 3 needs to be assigned a role that @@ -156,7 +156,7 @@ you, it may also be given permission for the scope of an entire resource group, or the whole subscription to allow create other peerings later without assigning the role again for each VNet separately. -7. Create a service principal for the Aiven application object +7. create a service principal for the Aiven application object ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Aiven AD tenant contains an application object (similar to the one @@ -179,7 +179,7 @@ tenant" then your account does not have the correct permissions. Please use an account with at least the **Application administrator** role assigned. -8. Create a custom role for the Aiven application object +8. create a custom role for the Aiven application object ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Aiven application now has a service principal that can be given @@ -198,7 +198,7 @@ include. Save the ``id`` field from the output - this will be referred to as ``$aiven_role_id`` -9. Assign the custom role to the Aiven service principal +9. assign the custom role to the Aiven service principal ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To give the Aiven application object's service principal permissions to @@ -211,7 +211,7 @@ with az role assignment create --role $aiven_role_id --assignee-object-id $aiven_sp_id --scope $user_vnet_id -10. Find your AD tenant id +10. find your AD tenant id ~~~~~~~~~~~~~~~~~~~~~~~~~~ The ID of your AD tenant will be needed in the next step. Find it from @@ -226,7 +226,7 @@ saving the ``tenantId`` field from the output. It will be referred to as ``$user_tenant_id`` later -11. Create a peering connection from the Aiven Project VPC +11. create a peering connection from the Aiven Project VPC ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This leads to the Aiven platform creating a peering from the VNet in the @@ -252,7 +252,7 @@ currently only accepts names in lower case. If no error is shown, the peering connection is being set up by the Aiven platform. -12. Wait for the Aiven platform to set up the connection +12. wait for the Aiven platform to set up the connection ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Run the following command until the state is no longer ``APPROVED`` , @@ -276,7 +276,7 @@ Save the ``to-tenant-id`` field from the output. It will be referred to as the ``aiven_tenant_id`` later. The ``to-network-id`` field from the output is referred to as the ``$aiven_vnet_id`` -13. Create peering from your VNet to the VNet of the project VPC +13. create peering from your VNet to the VNet of the project VPC ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Log out the Azure user you logged in with in step 1 using @@ -322,7 +322,7 @@ the role assignment in step 6 was correct. The client '' with object id '' does not have authorization to perform action 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings/write' over scope '$user_vnet_id' If access was recently granted, please refresh your credentials. -14. Wait until the Aiven peering connection is active +14. wait until the Aiven peering connection is active ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Aiven platform polls peering connections in state ``PENDING_PEER`` diff --git a/docs/products/clickhouse/howto/connect-to-grafana.rst b/docs/products/clickhouse/howto/connect-to-grafana.rst index 07baf7a630..858e326a43 100644 --- a/docs/products/clickhouse/howto/connect-to-grafana.rst +++ b/docs/products/clickhouse/howto/connect-to-grafana.rst @@ -30,6 +30,6 @@ Integrate ClickHouse® with Grafana® #. Set *URL* to ``CLICKHOUSE_HTTPS_URI``. #. In *Auth* section, enable **Basic auth** and **With Credentials**. #. In *Basic Auth Details*, set your ``CLICKHOUSE_USER`` and ``CLICKHOUSE_PASSWORD``. -#. Selec **Save & test**. +#. Select **Save & test**. Now you can create a dashboard and panels to work with the data from your Aiven for ClickHouse® service. diff --git a/docs/tools/cli/service/schema-registry-acl.rst b/docs/tools/cli/service/schema-registry-acl.rst index 7f1d2321dd..b5e51aafab 100644 --- a/docs/tools/cli/service/schema-registry-acl.rst +++ b/docs/tools/cli/service/schema-registry-acl.rst @@ -32,7 +32,7 @@ Where: - ``schema_registry_read`` - ``schema_registry_write`` * - ``--resource`` - - The resource format can be ``Config:`` or ``Subject:``. For more information, see `ACLs definition `. + - The resource format can be ``Config:`` or ``Subject:``. For more information, see :doc:`ACLs definition `. * - ``--username`` - The name of a service user