Deploying Control Plane On SLE16: Troubleshooting Guide

by Admin 56 views
Deploying Control Plane on SLE16: A Troubleshooting Guide

Hey guys! So, as we talked about, I've been wrestling with getting the control plane deployed using a SLE16 image on my local VM and the deployer VM. It's been a bit of a journey, but hey, that's what we're here for, right? I've documented the whole process, including the extra steps I had to take to get things working. Hopefully, this helps you avoid some of the headaches I faced! Let's dive in.

Setting Up the Deployer VM

First things first, I set up the Deployer VM on a local QEMU-based VM using the SLE16 online install media. I had to do a few tweaks to get the setup to match what the configure_deployer.sh script expects. Here's a quick rundown of the changes:

  • Disabled firewalld service: Probably not needed, but better safe than sorry, right?

  • Enabled sshd service: This one's a must. It's how I connect to the VM from my local machine.

  • Created a local user azureadm: The script seems to like this username, so I created it to match and avoid any potential issues.

  • Gave azureadm passwordless sudo permissions: This was key. Here's the command I used:

    echo "%wheel ALL = (ALL) NOPASSWD:ALL" > /usr/etc/sudoers.d/50-wheel-auth-self

    This lets the azureadm user run commands with sudo without needing a password. Super handy!

I understand that setting up the deployer VM is the foundational step in deploying the control plane. This is where the initial configurations and dependencies are set up before the actual deployment process begins. It's like preparing the kitchen before you start cooking – everything needs to be in place. If this is not done correctly, the deployer will not work as expected and the Control Plane deployment will fail, which can be time-consuming and frustrating.

Executing configure_deployer.sh

Now, for the fun part: running configure_deployer.sh. All the changes I made can be found in my personal fork. You can check it out for a closer look: https://github.com/sdaf-suse/sap-automation/compare/main...lpalovsky:sap-automation:sle16. I've been using this fork instead of the main repo. Let's look at the issues I faced here.

Dealing with Python Version Issues

When I first tried to run the script, it bombed out because it was using Python 3.6. Here's the error message:

az config set extension.use_dynamic_install=yes_without_prompt
+ az config set extension.use_dynamic_install=yes_without_prompt
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "/usr/lib64/az/lib/python3.6/site-packages/azure/cli/__main__.py", line 38, in <module>
az_cli = get_default_cli()
File "/usr/lib64/az/lib/python3.6/site-packages/azure/cli/core/__init__.py", line 903, in get_default_cli
from azure.cli.core.azlogging import AzCliLogging
File "/usr/lib64/az/lib/python3.6/site-packages/azure/cli/core/commands/events import EVENT_INVOKER_PRE_CMD_TBL_TRUNCATE
File "/usr/lib64/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 25, in <module>
from azure.cli.core.extension import get_extension
File "/usr/lib64/az/lib/python3.6/site-packages/azure/cli/core/extension/__init__.py", line 11, in <module>
from distutils.sysconfig import get_python_lib
ModuleNotFoundError: No module named 'distutils'

Solution:

  1. Ansible Version: To solve this, I changed the Ansible version in the script to 2.18: ansible_version="2.18". This is a crucial step when configuring the Ansible environment, as it ensures compatibility with the required modules and dependencies. Different versions of Ansible can have varying levels of support for certain features or Python versions, so selecting the appropriate version is critical to avoid compatibility issues during deployment.

  2. Azure CLI Installation: I installed the Azure CLI using pip, because the zypper version was linked to Python 3.6.

    sudo pip install --upgrade pip
sudo python3 -m pip install azure-cli

    This ensures that you're using the correct version of the Azure CLI, which is necessary for interacting with Azure resources. Using pip to install packages is standard practice in Python environments. If you are not familiar with these commands, make sure you know what are you doing to prevent further issues.

  3. Removed az-cli Zypper Installation: I removed the az-cli zypper installation from the script so that the pip version doesn't get overwritten. This step is necessary to avoid conflicts between the different package managers and ensure a consistent installation of the Azure CLI, particularly when the system uses multiple package management tools. Overriding the pip version with zypper can lead to problems, especially if there are compatibility issues between them.

  4. Modified az-cli Binary Path: I changed the az-cli binary path to /usr/local/bin/az. This ensures that the system uses the correct version of the Azure CLI, especially after the pip installation.

    sed -i s'/\/usr\/bin\/az/\/usr\/local\/bin\/az/'g configure_deployer.sh

  5. Installed virtualenv Package: I installed the missing virtualenv package.

    sudo zypper install -y python3-virtualenv

    This ensures that the deployment environment is correctly set up with all the necessary tools and libraries, enabling a smooth and error-free execution of the deployment process. The virtualenv package allows you to create isolated Python environments, which prevents conflicts between different projects and ensures that the required dependencies are installed correctly.

Dealing with Repository Issues

Because there is no PAYG image yet, I used BYOS. This led to errors related to missing repositories. This is the error I got:

{"@level":"error","@message":"Error: creating/updating Extension (Subscription: \"0f2a99ba-10c7-4dd8-83fe-90c313f48030\"
ResourceGroup Name: \"OpenQA-SDAF-PRD-DEPLOYER-swedencentral\"
Virtual Machine Name: \"PRD-SECE-DEP00_prdsecedep00deploy00\"
Extension Name: \"configure_deployer\"): polling after CreateOrUpdate: polling failed: the Azure API returned the following error:\n\nStatus: \"VMExtensionProvisioningError\"
Code: \"\"
Message: \"VM has reported a failure when processing extension 'configure_deployer'

***
ansible_collections=/opt/ansible/collections\\n+ ansible_pip3=/opt/ansible/venv/2.11/bin/pip3\\n+ sudo python3 -m pip install virtualenv\\n/usr/bin/python3: No module named pip\\n'.

***

Solution: Register and install pip. This is a common issue when setting up new environments.

Permission Issues in Library Deployment

During the library deployment, I ran into some permission-related issues, leading to failures.

Initializing the backend...
Terraform detected that the backend type changed from "local" to "azurerm".

Initializing modules...
╷
│ Error: Error inspecting states in the "local" backend:
│     listing blobs: executing request: unexpected status 403 (403 This request is not authorized to perform this operation using this permission.) with AuthorizationPermissionMismatch: This request is not authorized to perform this operation using this permission.
│ RequestId:d74bb8a8-301e-0061-6ec0-4cc112000000
│ Time:2025-11-03T12:51:03.7430948Z
│
│ Prior to changing backends, Terraform inspects the source and destination
│ states to determine what kind of migration steps need to be taken, if any.
│ Terraform failed to load the states. The data in both the source and the
│ destination remain unmodified. Please resolve the above error and try again.
│
│
╵

Terraform init:                        failed


Migrating the Deployer state failed

This error indicates that Terraform is having trouble accessing the Azure storage account to manage its state. This typically happens when the Azure service principal used by Terraform doesn't have the necessary permissions. The error message This request is not authorized to perform this operation using this permission is a key indicator that access to the Azure storage account is not permitted.

To resolve this, you'll need to ensure that the service principal used by Terraform has the correct permissions to access the storage account. The permissions required usually include roles like