diff --git a/docs/guides/configuration-guide/manager.mdx b/docs/guides/configuration-guide/manager.mdx index 20e7e06cf1..5235549c59 100644 --- a/docs/guides/configuration-guide/manager.mdx +++ b/docs/guides/configuration-guide/manager.mdx @@ -22,8 +22,8 @@ In the example, OSISM release 7.0.5 is used. 1. Set the new manager version in the configuration repository. ``` - MANAGER_VERSION=7.0.5 - sed -i -e "s/manager_version: .*/manager_version: ${MANAGER_VERSION}/g" environments/manager/configuration.yml + UPGRADE_RELEASE="7.0.5" + sed -i "~s,^manager_version:.*\$,manager_version: ${UPGRADE_RELEASE}," environments/manager/configuration.yml ``` 2. If `openstack_version` or `ceph_version` are set in `environments/manager/configuration.yml` @@ -41,10 +41,11 @@ In the example, OSISM release 7.0.5 is used. If Gilt is not installed via the `requirements.txt` of the manager environment it is important to use a version smaller v2. The v2 of Gilt is not yet usable. - ``` - gilt overlay # you have to do this 2x, this is not a copy & paste error - gilt overlay + python3 -m venv venv + source venv/bin/activate + pip install -r requirements.txt + gilt overlay && gilt overlay ``` Optionally, this is normally not necessary, it is possible to reference a specific tag of the @@ -63,11 +64,48 @@ In the example, OSISM release 7.0.5 is used. workflows for changes to the configuration repository, only a generic example for Git. ``` - git commit -a -s -m "manager: use OSISM version 7.0.5" + git commit -a -s -m "manager: use OSISM version ${UPGRADE_RELEASE?}" git push ``` -5. The upgrade is described in the [Manager Upgrade Guide](../upgrade-guide/manager). +## Working with GIT-Branches + +:::info + +For example, for compliance and security reasons, many organizations prefer to prepare changes to +production systems on dedicated Git branches, roll them out to the production environment +using the 4-eyes control principle and then finally transfer them to the `main` branch through a +review and release process. + +A typical scenario is the [Manager Upgrade](../upgrade-guide/manager.mdx). + +OSISM offers the option of using specific GIT branches on the Manager. + +::: + +The branch can be changed in the following way: + +1. Create a branch + ```bash + git checkout -b YOUR-BRANCH-FOR-CHANGE-XYZ + ``` +2. Set the branch name of your deployment branch with the variable `configuration_git_version` in `configuration.yml`. + This needs always to be changed on the manager node later if you merge the current branch to another target branch. + ```bash + BRANCH="$(git rev-parse --abbrev-ref HEAD)" + sed -i "~s,^configuration_git_version:.*\$,configuration_git_version: ${BRANCH}," environments/configuration.yml + git commit -m "Starting to work on #" -s environment/configuration.yml + git push + ``` +3. Login to the manager and activate the branch + (not needed when performing a initial manager install ) + ```bash + cd /opt/configuration + git fetch + git checkout YOUR-BRANCH-FOR-CHANGE-XYZ + osism apply configuration + ``` +4. Start your work on the topic and perfom a final review when the topic is complete ## OpenSearch integration diff --git a/docs/guides/deploy-guide/bootstrap.md b/docs/guides/deploy-guide/bootstrap.md index 744a6e1075..c7c483993b 100644 --- a/docs/guides/deploy-guide/bootstrap.md +++ b/docs/guides/deploy-guide/bootstrap.md @@ -22,78 +22,131 @@ The guide for this can be found in the section [Provisioning of bare-metal nodes The following steps are applied to bootstrap all nodes. After the completion of the bootstrap, the nodes are already ready for use. -1. Create operator user. - ``` - osism apply operator -u osism - ``` +## Group assignments - * When using the [osism/node-image](https://github.com/osism/node-image) the user is `osism` - and the password of this user is `password`. If you install Ubuntu manually the user usually - is `ubuntu`. If you want to use any other user here, that's no problem. It is important that - this user has sudo rights. The password according to what you have set yourself. +Assign the nodes to the suitable roles in `inventory/20-roles` - * The operator public SSH key has to be added in advance on all nodes to `authorized_keys` file - of the user specified with `-u`. This key is stored as `operator_public_key` in the file - `environments/configuration.yml`. +* Assign all nodes to the "generic" group +* Assign the nodes to the suitable groups - Alternatively (not recommended), the password can be stored in plain text in a file `/opt/configuration/secrets/conn_password`. - The parameter `--conn-pass-file /opt/configuration/secrets/conn_password` must then also be specified: - ``` - osism apply operator -u osism \ - --conn-pass-file /opt/configuration/secrets/conn_password - ``` +TODO: Does it make sense to describe the purpose of the groups with a few words to +help newbies to make the right descicions? - * It is important that this user has sudo rights with `NOPASSWD`. +| Groupname | Description | +|-----------------------|-------------------------------------------------------| +| `[generic]` | Roles which do not have any service specific settings | +| `[manager]` | Roles for the manager nodes | +| `[monitoring]` | The log, metric and alerting infrastructure roles | +| `[control]` | Openstack contoller roles | +| `[compute]` | Openstack compute nodes roles | +| `[ceph-control]` | Ceph mon servers | +| `[ceph-resource]` | Ceph OSDs, ... | +| `[ceph-rgw:children]` | Rados Gateway roles | - Alternatively (not recommended), the password can be stored in plain text in a file `/opt/configuration/secrets/become_password`. - The parameter `--become-pass-file /opt/configuration/secrets/become_password` must then also be specified: - ``` - osism apply operator -u osism \ - --become-pass-file /opt/configuration/secrets/become_password - ``` +## Create operator user - * If a password is required for both sudo and login, use both arguments at the same time. +Ansible must be given access to the systems so that OSISM can orchestrate the systems. - ``` - osism apply operator -u osism \ - --become-pass-file /opt/configuration/secrets/become_password \ - --conn-pass-file /opt/configuration/secrets/conn_password - ``` +In principle, this is achieved by the operator role. The basic command for this is as follows: +``` +osism apply operator -u osism +`` - * When using the [osism/node-image](https://github.com/osism/node-image) the user is `osism` and the password of this - user is `password`. If you install Ubuntu manually the user usually is `ubuntu`. The password according to what you - have set yourself +Initial access to set up access can either be via a known password or an SSH public key already stored on the system can be used for this. -2. Proxy deployment (optional). This is only necessary if you use the proxy on the manager to enable external access to - the nodes. +The operator public SSH key has to be added in advance on all nodes to `authorized_keys` file +of the user specified with `-u`. This key is stored as `operator_public_key` in the file +`environments/configuration.yml`. - ``` - osism apply squid - ``` +It is important that this user has sudo rights with `NOPASSWD` to get root access for perfoming automations. -3. Proxy configuration (optional). This is only necessary if you use the proxy on the manager to enable external access to - the nodes. +Alternatively (not recommended), the password can be stored in plain text in a file `/opt/configuration/secrets/become_password`. +The parameter `--become-pass-file /opt/configuration/secrets/become_password` must then also be specified: - ``` - osism apply proxy - ``` +``` +osism apply operator -u osism \ + --become-pass-file /opt/configuration/secrets/become_password +``` + +:::warning + +The initial user (specified i.e. with `-u osism`) will not be deactivated by default. +It is a good idea to delete the user at this point of the installation so that the user does not +accidentally remain active on the system with their known password and attackers can exploit this. +This can be achieved via the [`user_delete` array in the `user` role](https://github.com/osism/ansible-collection-commons/blob/main/roles/user/defaults/main.yml). + +::: + + +### Use a SSH public key + +This is the recommended way. + +When using custom [osism/node-image](https://github.com/osism/node-image) the build argument `ssh_public_key_user_osism` can be used +to add the public key to the node image. +If you us this method, no additional flags are needed for executing the "operator" role. + +### Use a password -4. Network configuration. It is recommended to backup the existing network configuration. +When using the [osism/node-image](https://github.com/osism/node-image) the user is `osism` +and the password of this user is `password`. If you install Ubuntu manually the user usually +is `ubuntu`. If you want to use any other user here, that's no problem. It is important that +this user has sudo rights. The password according to what you have set yourself. +When using a custom [osism/node-image](https://github.com/osism/node-image) the build argument `password_hash` can be used +to define your own password for the node image. + + +The parameter `--conn-pass-file /opt/configuration/secrets/conn_password` must be specified: + +``` +echo "password" > /opt/configuration/secrets/conn_password +osism apply operator -u osism \ + --limit 'all:!manager' \ + --conn-pass-file /opt/configuration/secrets/conn_password +``` + +If a password is required for both sudo and login, use both arguments at the same time. + +``` +osism apply operator -u osism \ + --become-pass-file /opt/configuration/secrets/become_password \ + --conn-pass-file /opt/configuration/secrets/conn_password +``` + +## Optional: Using a proxy with your environment + +The proxy deployment is optional. This is only necessary if you use the proxy on the manager to enable external access of +the nodes to the internet. + +Deploy squid proxy on the manager: +``` +osism apply squid +``` + +Configure the proxy values unter `proxy_proxies` and `docker_configure_proxy`. +This is only necessary if you use the proxy on the manager to enable external access to the nodes. +``` +osism apply proxy +``` + +## Network configuration. It is recommended to backup the existing network configuration. + +1. Configure the network setup ``` osism apply network ``` -5. Reboot (optional). The reboot at this point is recommended to ensure that the network configuration is working. +2. Recommendend, but not mandatory: The reboot at this point is recommended to ensure that the network configuration is working. ``` osism apply reboot -l 'all:!manager' -e ireallymeanit=yes ``` -6. Check if all systems are reachable (you probably have to do this several times until all systems are accessible). +3. Check if all systems are reachable (you probably have to do this several times until all systems are accessible). ``` osism apply ping @@ -114,41 +167,45 @@ the nodes are already ready for use. to host\r", "unreachable": true} ``` -7. Refresh facts. +## Bootstrap the nodes + +1. [Refresh facts](../operations-guide/manager/facts). ``` osism apply facts ``` -8. Bootstrap. +2. Bootstrap nodes ``` - osism apply bootstrap + osism apply bootstrap -l 'all:!manager' ``` -9. Reboot (non-optional). Since the kernel version often changes after the initial bootstrap, +3. Reboot (non-optional). Since the kernel version often changes after the initial bootstrap, the reboot should always be performed. ``` osism apply reboot -l 'all:!manager' -e ireallymeanit=yes ``` -10. Check if all systems are reachable (you probably have to do this several times until all systems are accessible). +4. Check if all systems are reachable (you probably have to do this several times until all systems are accessible). + + ``` + osism apply ping + ``` - ``` - osism apply ping - ``` +## Finalize Boostrapping -11. Prepare the SSH configuration of the manager node. +1. Prepare the SSH configuration of the manager node. - ``` - osism apply sshconfig - ``` + ``` + osism apply sshconfig + ``` -12. Make all SSH public keys known. +2. Make all SSH public keys known. - ``` - osism apply known-hosts - ``` + ``` + osism apply known-hosts + ``` Ready. All nodes are now bootstrapped and available to deploy services. diff --git a/docs/guides/deploy-guide/index.md b/docs/guides/deploy-guide/index.md index f7e6be5171..abf4d4a6d9 100644 --- a/docs/guides/deploy-guide/index.md +++ b/docs/guides/deploy-guide/index.md @@ -15,8 +15,10 @@ What a configuration repository is and how it is created is described in the ::: -* Step 1: [Preparation of the seed node](./seed) -* Step 2: [Preparation of the manager node](./manager) -* Step 3: [Provisioning of the bare-metal nodes](./provisioning) -* Step 4: [Bootstrap of the bare-metal nodes](./bootstrap) -* Step 5: [Deployment of the services](./services) +* Step 1: [Creation of a configuration repository](../configuration-guide/configuration-repository#creating-a-new-configuration-repository) +* Step 2: [Preparation of the seed node](./seed) +* Step 3: [Preparation of the manager node](./manager) +* Step 4: [Provisioning of the bare-metal nodes](./provisioning) +* Step 5: [Bootstrap of the bare-metal nodes](./bootstrap) +* Step 6: [Deployment of the services](./services) + diff --git a/docs/guides/deploy-guide/manager.md b/docs/guides/deploy-guide/manager.md index ad85a7868a..ca5f679bf6 100644 --- a/docs/guides/deploy-guide/manager.md +++ b/docs/guides/deploy-guide/manager.md @@ -42,6 +42,8 @@ on the seed node. The deployment of the seed node itself is documented in the ``` cd environments/manager ``` +If you are working with git branches, +read [the instructions](../configuration-guide/manager.mdx). ### Step 1: Create operator user @@ -67,7 +69,7 @@ ANSIBLE_USER=osism \ ./run.sh operator ``` -When the `./run.sh operator` is executed, the following prompts are displayed. +When the `./run.sh operator` is executed, the following prompts are displayed: | Prompt | Value | Comment | |:---------------------------------------------|:---------------------------------------------------|:-------------------------------------| @@ -75,6 +77,8 @@ When the `./run.sh operator` is executed, the following prompts are displayed. | `BECOME password[defaults to SSH password]:` | Password so that the `ANSIBLE_USER` can use `sudo` | Enabled by `ANSIBLE_BECOME_ASK_PASS` | | `Vault password:` | Value of `secrets/vaultpass` | Enabled by `ANSIBLE_ASK_VAULT_PASS` | +**Useful information if something goes wrong in the step described** + * If a password is required to login to the manager node, `ANSIBLE_ASK_PASS=True` must be set. * If an SSH key is required to login to the manager node, the key has to be added on the manager node to `~/.ssh/authorized_keys` in the home directory of the user specified as `ANSIBLE_USER` first. @@ -112,13 +116,15 @@ in the Ansible documentation. | `ANSIBLE_BECOME_ASK_PASS` | Boolean | Toggle to prompt for privilege escalation password. | | `ANSIBLE_SSH_ARGS` | String | If set, this will override the Ansible default ssh arguments. | | `ANSIBLE_USER` | String | The user Ansible ‘logs in’ as. | -To verify the creation of the operator user, use the private key file `id_rsa.operator`. Make + + +To verify the proper creation of the operator user, use the private key file `id_rsa.operator`. Make sure you purge all keys from ssh-agent identity cache using `ssh-add -D`. You can print the list using `ssh-add -l`. The list should be empty. ``` ssh-add -D -ssh -o IdentitiesOnly=yes -i id_rsa.operator dragon@testbed-manager +ssh -o IdentitiesOnly=yes -i PATH_TO_YOUR_SECRETS/id_rsa.operator dragon@YOUR_MANAGER_NODE ``` ### Step 2: Apply the network configuration @@ -140,7 +146,7 @@ Then you can deploy the network configuration with the network role. ./run.sh network ``` -Upon completion of the network configurtion, a node reboot should be performed to ensure the configuration +Upon completion of the network configuration, a node reboot should be performed to ensure the configuration is functional and reboot safe. Since network services are not restarted automatically, later changes to the network configuration are not effective without a manual apply of the network configuration or reboot of the nodes. @@ -199,9 +205,9 @@ Finally, the Ansible Vault password is made known on the manager node. Before th with the `dragon` user. ``` +ssh -o IdentitiesOnly=yes -i PATH_TO_YOUR_SECRETS/id_rsa.operator dragon@YOUR_MANAGER_NODE osism set vault password -Ansible Vault password: ******** ``` -Ready. The manager is now prepared and you can continue with the bootstrap of the other nodes. -The seed node used until here is no longer necessary. +Ready. The manager is now prepared, and you can continue with the bootstrap of the other nodes. +The seed node used until here is now no longer necessary. diff --git a/docs/guides/deploy-guide/provisioning.md b/docs/guides/deploy-guide/provisioning.md index 9a32424543..d0c4a77022 100644 --- a/docs/guides/deploy-guide/provisioning.md +++ b/docs/guides/deploy-guide/provisioning.md @@ -17,9 +17,35 @@ control plane manually. An ISO image is provided for this purpose which automati provisions a node. The ISO images are available for download in the [osism/node-image](https://github.com/osism/node-image) repository. +## Automated Installation using Node Images + There are different variants of the ISO image. The variants differ in the disc layout. -The available variants are described in the README file of the [osism/node-image](https://github.com/osism/node-image) -repository. + +The pre-build variants are described in the README file of the +[osism/node-image](https://github.com/osism/node-image/blob/main/README.md) repository. + +A good way to provision the nodes is to use virtual media mounts via the usually available Redfish +functionality of the BMC of the servers used. In this way, the basic installation can be carried +out without external dependencies such as adapting the switch configuration, DHCP, upstream connectivity, etc. +In many cases, this simplifies the process, makes it more automation-friendly and avoids potential sources of error. + +OSISM also provides a tool to generate node images specific for you needs. + +This makes particular sense for the node-provisioning in the following situations: + +* Make complex configurations like layer3 underlay +* Add your SSH keys to the image +* Configure a specific root password +* Change other characteristics of the setup + * Templates + * Partitioning + * Packages + * ... +* Develop new standard images + +The procedures for building custom images are described in the +[osism/node-image](https://github.com/osism/node-image/blob/main/README.md) repository. + ## Manual provisioning diff --git a/docs/guides/deploy-guide/seed.md b/docs/guides/deploy-guide/seed.md index ac226e6868..abf96007f4 100644 --- a/docs/guides/deploy-guide/seed.md +++ b/docs/guides/deploy-guide/seed.md @@ -28,7 +28,7 @@ the seed node. ## Install required packages ``` -sudo apt-get install git python3-pip python3-virtualenv sshpass +sudo apt-get install git python3-pip python3-virtualenv sshpass libssh-dev ``` ## Get a copy of the configuration repository diff --git a/docs/guides/deploy-guide/services/index.md b/docs/guides/deploy-guide/services/index.md index b41736a26b..d8cd3c2a88 100644 --- a/docs/guides/deploy-guide/services/index.md +++ b/docs/guides/deploy-guide/services/index.md @@ -20,3 +20,10 @@ When setting up a new cluster, the services are deployed in a specific order. 3. [Logging & Monitoring](./logging-monitoring) 4. [Ceph](./ceph) 5. [OpenStack](./openstack) + + +In the examples, the pull of images (if supported by a role) is always run first. While +this is optional, it is recommended to speed up the execution of the deploy action in +the second step. This significantly reduces the times required for the restart from a +service. + diff --git a/docs/guides/operations-guide/index.md b/docs/guides/operations-guide/index.md index 25f37e377e..5a336a8684 100644 --- a/docs/guides/operations-guide/index.md +++ b/docs/guides/operations-guide/index.md @@ -33,31 +33,6 @@ osism noset bootstrap NODE * Ansible fact: `ansible_local.osism.bootstrap` * State file: `/etc/osism/bootstrap` -## Use of custom plays - -Custom Plays can be used in all environments in the configuration repository. - -For example, this is a play to prepare all devices to be used for Ceph on a Ceph -resource node. It is saved in the configuration repository in the file -`environments/ceph/playbook-wipe-partitions.yml`. It is run with -`osism apply -e ceph wipe-parititons`. - -```yaml title="environments/ceph/playbook-wipe-partitions.yml ---- -- name: Wipe partitions - hosts: ceph-resource - gather_facts: false - - tasks: - - name: Wipe partitions - become: true - ansible.builtin.shell: | - wipefs --all "{{ item }}" - dd if=/dev/zero of="{{ item }}" bs=1 count=4096 - changed_when: false - with_items: "{{ devices }}" -``` - ## Manage services ``` diff --git a/docs/guides/operations-guide/manager/apply.md b/docs/guides/operations-guide/manager/apply.md index b3b78bc5a1..67cd175112 100644 --- a/docs/guides/operations-guide/manager/apply.md +++ b/docs/guides/operations-guide/manager/apply.md @@ -4,6 +4,10 @@ sidebar_label: Apply # Apply + +Applies are there to roll out Ansible Plays. These are executed as background activity via a queuing system so that, for example, the loss of an SSH connection does not result in the execution being aborted. +In this case, the logs can also be analyzed [retrospectively](./log). + ## List all available plays ``` @@ -34,3 +38,58 @@ $ osism apply | iscsi | kolla | ... ``` + +It's also possible to have custom plays, this is [described in the operations guide](). + +## Apply a role + +``` +$ osism apply operator -l st01-mgmt-r01-u30 +2024-06-14 09:33:10 | INFO | Task f94a2e6f-d199-421c-b7b7-743db4661305 (operator) was prepared for execution. +2024-06-14 09:33:10 | INFO | It takes a moment until task f94a2e6f-d199-421c-b7b7-743db4661305 (operator) has been started and output is visible here. + +PLAY [Make ssh pipelining working] ********************************************* + +TASK [Do not require tty for all users] **************************************** +ok: [st01-mgmt-r01-u30] + +... +... + +TASK [osism.commons.operator : Set password of operator user] ****************** +ok: [st01-mgmt-r01-u30] + +TASK [osism.commons.operator : Set root password like operator password] ******* +ok: [st01-mgmt-r01-u30] + +PLAY RECAP ********************************************************************* +2024-06-14 09:34:14 | INFO | Play has been completed. There may now be a delay until all logs have been written. +2024-06-14 09:34:14 | INFO | Please wait and do not abort execution. +st01-mgmt-r01-u30 : ok=11 changed=0 unreachable=0 failed=0 skipped=5 rescued=0 ignored=0 +``` + +## Use of custom plays + +Custom Plays can be used in all environments in the configuration repository. + +For example, this is a play to prepare all devices to be used for Ceph on a Ceph +resource node. It is saved in the configuration repository in the file +`environments/ceph/playbook-wipe-partitions.yml`. It is run with +`osism apply -e ceph wipe-parititons`. + +```yaml title="environments/ceph/playbook-wipe-partitions.yml +--- +- name: Wipe partitions + hosts: ceph-resource + gather_facts: false + + tasks: + - name: Wipe partitions + become: true + ansible.builtin.shell: | + wipefs --all "{{ item }}" + dd if=/dev/zero of="{{ item }}" bs=1 count=4096 + changed_when: false + with_items: "{{ devices }}" +``` + diff --git a/docs/guides/operations-guide/manager/facts.md b/docs/guides/operations-guide/manager/facts.md new file mode 100644 index 0000000000..5a521792b9 --- /dev/null +++ b/docs/guides/operations-guide/manager/facts.md @@ -0,0 +1,17 @@ +--- +sidebar_label: Facts +--- + +# Facts + +TODOs: + +- What exactly is this step responsible for and what purpose does it serve? +- When should this task to executed? +- What is the technical background? +.... + +``` +osism apply facts +``` + diff --git a/docs/guides/operations-guide/manager/images/python-osism.drawio.png b/docs/guides/operations-guide/manager/images/python-osism.drawio.png index 7772f1484e..8de6e27229 100644 Binary files a/docs/guides/operations-guide/manager/images/python-osism.drawio.png and b/docs/guides/operations-guide/manager/images/python-osism.drawio.png differ diff --git a/docs/guides/operations-guide/manager/index.md b/docs/guides/operations-guide/manager/index.md index f0d94e6288..f33dc991b0 100644 --- a/docs/guides/operations-guide/manager/index.md +++ b/docs/guides/operations-guide/manager/index.md @@ -5,4 +5,31 @@ sidebar_position: 10 # Manager +## Architecture View + ![OSISM orchestrator](./images/python-osism.drawio.png) + +## OSISM Usage + +### Get help for OSISM commands + +``` +osism help +osism help apply +``` + +### Update the configuration + +Once the manager has been deployed and the configuration repository has been initially transferred to the manager node, +the configuration repository can be updated using osism apply configuration. + +Configuration changes are typically staged in a clone of the configuration repo to have versioning of changes. + +``` +cd /opt/configuration +git pull +osism apply configuration +``` + +If local changes were made directly in the configuration repository on the manager node, these are overwritten without asking. + diff --git a/docs/guides/operations-guide/manager/reconceiler.md b/docs/guides/operations-guide/manager/reconceiler.md new file mode 100644 index 0000000000..cef36901bc --- /dev/null +++ b/docs/guides/operations-guide/manager/reconceiler.md @@ -0,0 +1,21 @@ +--- +sidebar_label: Reconceiler +--- + +# Facts + +TODOs: + +- What exactly is this step responsible for and what purpose does it serve? +- When should this task to executed? +- What is the technical background? +.... + +### Rebuild the internal inventory + +Invoke the [inventory reconciliation](../../configuration-guide/inventory.md#reconciler). + +``` +osism reconciler sync +``` + diff --git a/docs/guides/operations-guide/openstack/octavia.md b/docs/guides/operations-guide/openstack/octavia.md index 45fa322795..bd066f1c7f 100644 --- a/docs/guides/operations-guide/openstack/octavia.md +++ b/docs/guides/operations-guide/openstack/octavia.md @@ -4,7 +4,7 @@ sidebar_label: Octavia # Octavia -## Cleanup of amphorae missing from the DB +## Cleanup of amphora missing from the DB ```none title="/var/log/kolla/octavia/octavia-health-manager.log" 2023-10-25 16:43:52.547 22 WARNING octavia.amphorae.drivers.health.heartbeat_udp [-] @@ -12,19 +12,3 @@ The amphora 2a33a889-4f9a-4340-84a5-e58a7a8af17e with IP 10.1.0.79 is missing fr DB, so it cannot be automatically deleted (the compute_id is unknown). An operator must manually delete it from the compute service. ``` - -## SSH access to amphorae - -1. Get the local IP address (`lb_network_ip`) of the amphora you want to access via - `openstack --os-cloud admin loadbalancer amphora list`. - -2. Connect to one of the nodes that you use for Octavia. Normally the control- - or network nodes. - -3. You can now use SSH to access the amphora. The use of sudo is required here because - you cannot access `/etc/kolla/octavia-worker/octavia_ssh_key` with the operator user - account. Replace `lb_network_ip` with the local IP address of the amphora. - - ``` - sudo ssh -i /etc/kolla/octavia-worker/octavia_ssh_key ubuntu@lb_network_ip - ``` diff --git a/docs/guides/operations-guide/openstack/tools/image-manager/index.md b/docs/guides/operations-guide/openstack/tools/image-manager/index.md index db86337914..5ba3e556f2 100644 --- a/docs/guides/operations-guide/openstack/tools/image-manager/index.md +++ b/docs/guides/operations-guide/openstack/tools/image-manager/index.md @@ -115,21 +115,22 @@ the help of the OpenStack Image Manager. visibility: private multi: false meta: - architecture: x86_64 - hw_disk_bus: scsi - hw_rng_model: virtio - hw_scsi_model: virtio-scsi - hw_watchdog_action: reset - os_distro: cirros - replace_frequency: never - uuid_validity: none - provided_until: none + architecture: x86_64 + hw_disk_bus: scsi + hw_rng_model: virtio + hw_scsi_model: virtio-scsi + hw_watchdog_action: reset + os_distro: cirros + replace_frequency: never + uuid_validity: none + provided_until: none tags: [] versions: - - version: "0.6.0" - url: https://github.com/cirros-dev/cirros/releases/download/0.6.0/cirros-0.6.0-x86_64-disk.img - checksum: "sha256:94e1e2c94dbbae7d4bdc38e68590a1daf73c9de2d03dd693857b4b0a042548e8" - build_date: 2022-09-28 + - version: '0.6.2' + url: https://github.com/cirros-dev/cirros/releases/download/0.6.2/cirros-0.6.2-x86_64-disk.img + checksum: "sha256:07e44a73e54c94d988028515403c1ed762055e01b83a767edf3c2b387f78ce00" + build_date: 2023-05-30 + ``` 3. Run the OpenStack Image Manager. It is assumed that a profile with the name `openstack` exists in the