Category: Cloud & DevOps

Generative AI (GenAI) is no longer a mystery—it’s been around for over two years now. Developers are leveraging GenAI for a wide range of tasks: writing code, handling customer queries, powering RAG pipelines for data retrieval, generating images and videos from text, and much more.

In this blog post, we’ll integrate an AI model directly into the shell, enabling real-time translation of natural language queries into Linux shell commands—no more copying and pasting from tools like ChatGPT or Google Gemini. Even if you’re a Linux power user who knows most commands by heart, there are always moments when a specific command escapes you. We’ll use Amazon Bedrock, a fully managed serverless service, to run inferences with the model of our choice. For development and testing, we’ll start with local model hosting using Ollama and Open WebUI. Shell integration examples will cover both Zsh and Bash.

Setting up Ollama and OpenWebUI for prompt testing

1. Install Ollama

curl -fsSL https://ollama.com/install.sh | sh

curl -fsSL https://ollama.com/install.sh | sh

2. Start Ollama service

systemctl enable ollama && systemctl start ollama

systemctl enable ollama && systemctl start ollama

By default, Ollama listens on port 11434. If you’re comfortable without a user interface like ChatGPT, you can start sending prompts directly to the /api/generate endpoint using tools like curl or Postman. Alternatively, you can run a model from the shell using:

ollama run <model_name>

ollama run <model_name>

3. Install open web ui

At this step we assume that you have python pip installed.

pip install open-webui

pip install open-webui

Now that Open WebUI is installed, let’s pull a model and begin prompt development. For this example, we’ll use the mistral model locally

4. Pull mistral:7b or mistral:latest model

ollama pull mistral:latest

ollama pull mistral:latest

5. Start Open-WebUI server

open-webui serve

open-webui serve

This starts the Open WebUI on the default port 8080. Open your favorite web browser and navigate to http://localhost:8080/. Set an initial username and password. Once configured, you’ll see an interface similar to ChatGPT. You can choose your model from the dropdown in the top-left corner.

Testing the prompt in Open-WebUI and with API calls:

Goal:

• User types a natural language query
• Model receives the input and processes it
• Model generates a structured JSON output
• The shell replaces the original query with the actual command

Why Structured Output Instead of Plain Text?

You might wonder—why not just instruct the model to return a plain shell command with strict prompting rules? During testing, we observed that even with rigid prompt instructions, the model occasionally includes explanatory text. This often happens when the command in question could be dangerous or needs caution.

For instance, the dd command can write directly to disk at a low level. Models like Mistral or Llama may append a warning or explanation along with the command to prevent accidental misuse. Using structured JSON helps us isolate the actual command cleanly, regardless of any extra text the model may generate.

The Prompt:

You are a linux system administrator and devops engineer assistant used in an automated system that parses your responses as raw JSON.
STRICT RULES:
- Output MUST be only valid raw JSON. Do NOT include markdown, backticks, or formatting tags.
- NO explanations, no introductory text, and no comments.
- If no suitable command is found, output: {"command": "", "notes": "no command found", "status": "error"}
- Output must always follow this exact schema:
{
    "command": "<actual Linux command here>",
    "notes": "<if applicable, add any notes to the command>",
    "status": "success/error"
}
- Any deviation from this format will result in system error.
Respond to the following user query as per the rules above:
<Query Here>

You are a linux system administrator and devops engineer assistant used in an automated system that parses your responses as raw JSON.
STRICT RULES:
- Output MUST be only valid raw JSON. Do NOT include markdown, backticks, or formatting tags.
- NO explanations, no introductory text, and no comments.
- If no suitable command is found, output: {"command": "", "notes": "no command found", "status": "error"}
- Output must always follow this exact schema:
{
    "command": "<actual Linux command here>",
    "notes": "<if applicable, add any notes to the command>",
    "status": "success/error"
}
- Any deviation from this format will result in system error.
Respond to the following user query as per the rules above:
<Query Here>

Let’s test it with the query:
“start nginx container backed by alpine image”

And here’s the structured response we get:

{
"command": "docker run -d --name my-nginx -p 80:80 -p 443:443 -v /etc/nginx/conf.d:/etc/nginx/conf.d nginx:alpine",  
"notes": "Replace 'my-nginx' with a suitable container name.",  
"status": "success"
}

{
"command": "docker run -d --name my-nginx -p 80:80 -p 443:443 -v /etc/nginx/conf.d:/etc/nginx/conf.d nginx:alpine",  
"notes": "Replace 'my-nginx' with a suitable container name.",  
"status": "success"
}

Bingo! This is exactly the output we expect—clean, structured, and ready for direct use.

Now that our prompt works as expected, we can test it directly via Ollama’s API.

Assuming your payload is saved in /tmp/payload.json, you can make the API call using curl:

{
  "model": "phi4:latest",
  "prompt": "You are a linux system administrator and devops engineer assistant used in an automated system that parses your responses as raw JSON.nSTRICT RULES:n- Output MUST be only valid raw JSON. Do NOT include markdown, backticks, or formatting tags.n- NO explanations, no introductory text, and no comments.n- If no suitable command is found, output: {"command": "", "notes": "no command found", "status": "error"}n- Output must always follow this exact schema:n{n    "command": "<actual Linux command here>",n    "notes": "<if applicable, add any notes to the command>",n    "status": "success/error"n}n- Any deviation from this format will result in system error.nRespond to the following user query as per the rules above:nstart nginx container backed by alpine image",
  "stream": false
}

{
  "model": "phi4:latest",
  "prompt": "You are a linux system administrator and devops engineer assistant used in an automated system that parses your responses as raw JSON.nSTRICT RULES:n- Output MUST be only valid raw JSON. Do NOT include markdown, backticks, or formatting tags.n- NO explanations, no introductory text, and no comments.n- If no suitable command is found, output: {"command": "", "notes": "no command found", "status": "error"}n- Output must always follow this exact schema:n{n    "command": "<actual Linux command here>",n    "notes": "<if applicable, add any notes to the command>",n    "status": "success/error"n}n- Any deviation from this format will result in system error.nRespond to the following user query as per the rules above:nstart nginx container backed by alpine image",
  "stream": false
}

curl -d @/tmp/payload.json -H 'Content-Type: application/json' 'http://localhost:11434/api/generate'

curl -d @/tmp/payload.json -H 'Content-Type: application/json' 'http://localhost:11434/api/generate'

Note: Ensure that smart quotes (‘’) are not used in your actual command—replace them with straight quotes (”) to avoid errors in the terminal.

This allows you to interact with the model programmatically, bypassing the UI and integrating the prompt into automated workflows or CLI tools.

Setting up AWS Bedrock Managed Service

Login to the AWS Console and navigate to the Bedrock service.

Under Foundation Models, filter by Serverless models.

Subscribe to a model that suits code generation use cases. For this blog, I’ve chosen Anthropic Claude 3.7 Sonnet, known for strong code generation capabilities.
Alternatively, you can go with Amazon Titan or Amazon Nova models, which are more cost-effective and often produce comparable results.

Configure Prompt Management

1. Once subscribed, go to the left sidebar and under Builder Tools, click on Prompt Management.

‍

2. Click Create prompt and give it a name—e.g., Shebang-NLP-TO-SHELL-CMD.

3. In the next window:

• Expand System Instructions and paste the structured prompt we tested earlier (excluding the <Query Here> placeholder).
• In the User Message, enter {{question}} — this will act as a placeholder for the user’s natural language query.

4. Under Generative AI Resource, select your subscribed model.

5. Leave the randomness and diversity settings as default. You may reduce the temperature slightly to get more deterministic responses, depending on your needs.

6. At the bottom of the screen, you should see the question variable under the Test Variables section.
Add a sample value like: list all docker containers

7. Click Run. You should see the structured JSON response on the right pane.

8. If the output looks good, click Create Version to save your tested prompt.

Setting Up a “Flow” in AWS Bedrock

1. From the left sidebar under Builder Tools, click on Flows.

‍

2. Click the Create Flow button.

• Name your flow (e.g., ShebangShellFlow).
• Keep the “Create and use a new service role” checkbox selected.
• Click Create flow.

Once created, you’ll see a flow graph with the following nodes:

• Flow Input
• Prompts
• Flow Output

Configure Nodes

• Click on the Flow Input and Flow Output nodes.
  Note down the Node Name and Output Name (default: FlowInputNode and document, respectively).
• Click on the Prompts node, then in the Configure tab on the left:
  • Select “Use prompt from prompt management” 
  • From the Prompt dropdown, select the one you created earlier.
  • Choose the latest Version of the prompt.
  • Click Save.

Test the Flow

You can now test the flow by providing a sample natural language input like:

list all docker containers

Finalizing the Flow

1. Go back to the Flows list and select the flow you just created.

2. Note down the Flow ID or ARN.

3. Click Publish Version to create the first version of your flow.

4. Navigate to the Aliases tab and click Create Alias:

• Name your alias (e.g., prod or v1).
• Choose “Use existing version to associate this alias”.
• From the Version dropdown, select Version 1.
  Click Create alias.

5. After it’s created, click on the new alias under the Aliases tab and note the Alias ARN—you’ll need this when calling the flow programmatically.

Shell Integration for ZSH and BASH

Configuring IAM Policy

To use the Bedrock flow from your CLI, you need a minimal IAM policy as shown below:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeFlow"
      ],
      "Resource": "<flow resource arn>"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeFlow"
      ],
      "Resource": "<flow resource arn>"
    }
  ]
}

Attach this policy to the IAM user whose credentials you’ll use for invoking the flow.

Note: This guide does not cover AWS credential configuration (e.g., ~/.aws/credentials).

Bedrock Flow API

AWS provides a REST endpoint to invoke a Bedrock flow:

`/flows/<flowIdentifier>/aliases/<flowAliasIdentifier>`

You can find the official API documentation here:
InvokeFlow API Reference

To simplify request signing (e.g., AWS SigV4), language-specific SDKs are available. For this example, we use the AWS SDK v3 for JavaScript and the InvokeFlowCommand from the @aws-sdk/client-bedrock-agent-runtime package:

SDK Reference:
https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/bedrock-agent-runtime/command/InvokeFlowCommand/

Required Parameters

You’ll need to substitute the following values in your SDK/API calls:

• flowIdentifier: ID or ARN of the Bedrock flow
• flowAliasIdentifier: Alias ARN of the flow version
• nodeName: Usually FlowInputNode
• content.document: Natural language query
• nodeOutputName: Usually document

Shell Script Integration

The Node.js script reads a natural language query from standard input (either piped or redirected) and invokes the Bedrock flow accordingly. You can find the full source code of this project in the GitHub repo:
https://github.com/azadsagar/ai-shell-helper

Environment Variables

To keep the script flexible across local and cloud-based inference, the following environment variables are used:

INFERENCE_MODE="<ollama|aws_bedrock>"
# For local inference
OLLAMA_URL="http://localhost:11434"
# For Bedrock inference
BEDROCK_FLOW_IDENTIFIER="<flow ID or ARN>"
BEDROCK_FLOW_ALIAS="<alias name or ARN>"
AWS_REGION="us-east-1"

INFERENCE_MODE="<ollama|aws_bedrock>"

# For local inference
OLLAMA_URL="http://localhost:11434"

# For Bedrock inference
BEDROCK_FLOW_IDENTIFIER="<flow ID or ARN>"
BEDROCK_FLOW_ALIAS="<alias name or ARN>"
AWS_REGION="us-east-1"

Set INFERENCE_MODE to ollama if you want to use a locally hosted model.

Configure ZSH/BASH shell to perform magic – Shebang

When you type in a Zsh shell, your input is captured in a shell variable called LBUFFER. This is a duplex variable—meaning it can be read and also written back to. Updating LBUFFER automatically updates your shell prompt in place.

In the case of Bash, the corresponding variable is READLINE_LINE. However, unlike Zsh, you must manually update the cursor position after modifying the input. You can do this by calculating the string length using ${#READLINE_LINE} and setting the cursor accordingly. This ensures the cursor moves to the end of the updated line.

From Natural Language to Shell Command

Typing natural language directly in the shell and pressing Enter would usually throw a “command not found” error. Instead, we’ll map a shortcut key to a shell function that:

• Captures the input (LBUFFER for Zsh, READLINE_LINE for Bash)
• Sends it to a Node.js script via standard input
• Replaces the shell line with the generated shell command

Zsh Integration Example

In Zsh, you must register the shell function as a Zsh widget, then bind it to a shortcut using bindkey.

function ai-command-widget() {
  alias ai-cmd='node $HOME/ai-shell-helper/main.js'
  local input
  input="$LBUFFER"
  local cmdout
  cmdout=$(echo "$input" | ai-cmd)
  # Replace current buffer with AI-generated command
  LBUFFER="$cmdout"
}
# Register the widget
zle -N ai-command-widget
# Bind Ctrl+G to the widget
bindkey '^G' ai-command-widget

function ai-command-widget() {
  alias ai-cmd='node $HOME/ai-shell-helper/main.js'

  local input
  input="$LBUFFER"
  local cmdout
  cmdout=$(echo "$input" | ai-cmd)

  # Replace current buffer with AI-generated command
  LBUFFER="$cmdout"
}

# Register the widget
zle -N ai-command-widget

# Bind Ctrl+G to the widget
bindkey '^G' ai-command-widget

Bash Integration Example

In Bash, the setup is slightly different. You bind the function using the bind command and use READLINE_LINE for input and output.

ai_command_widget() {
  local input="$READLINE_LINE"
  local cmdout
  cmdout=$(echo "$input" | node "$HOME/ai-shell-helper/main.js")
  READLINE_LINE="$cmdout"
  READLINE_POINT=${#READLINE_LINE}
}
# Bind Ctrl+G to the function
bind -x '"C-g": ai_command_widget'

ai_command_widget() {
  local input="$READLINE_LINE"
  local cmdout
  cmdout=$(echo "$input" | node "$HOME/ai-shell-helper/main.js")

  READLINE_LINE="$cmdout"
  READLINE_POINT=${#READLINE_LINE}
}

# Bind Ctrl+G to the function
bind -x '"C-g": ai_command_widget'

Note: Ensure that Node.js and npm are installed on your system before proceeding.

Quick Setup

If you’ve cloned the GitHub repo into your home directory, run the following to install dependencies and activate the integration:

cd ~/ai-shell-helper && npm install
# For Zsh
echo "source $HOME/ai-shell-helper/zsh_int.sh" >> ~/.zshrc
# For Bash
echo "source $HOME/ai-shell-helper/bash_int.sh" >> ~/.bashrc

cd ~/ai-shell-helper && npm install

# For Zsh
echo "source $HOME/ai-shell-helper/zsh_int.sh" >> ~/.zshrc

# For Bash
echo "source $HOME/ai-shell-helper/bash_int.sh" >> ~/.bashrc

Then, start a new terminal session.

Try It Out!

In your new shell, type a natural language query like:

list all docker containers

Now press Ctrl+G.
You’ll see your input replaced with the actual command:

docker ps -a

And that’s the magic of Shebang Shell with GenAI!

Demo Video:

‍

So, you’ve heard about OpenStack, but it sounds like a mythical beast only cloud wizards can tame? Fear not! No magic spells or enchanted scrolls are needed—we’re breaking it down in a simple, engaging, and fun way.

Ever felt like managing cloud infrastructure is like trying to tame a wild beast? OpenStack might seem intimidating at first, but with the right approach, it’s more like training a dragon —challenging but totally worth it!

By the end of this guide, you’ll not only understand OpenStack but also be able to deploy it like a pro using Kolla-Ansible. Let’s dive in! 🚀

🤔 What Is OpenStack?

Imagine you’re running an online store. Instead of buying an entire warehouse upfront, you rent shelf space, scaling up or down based on demand. That’s exactly how OpenStack works for computing!

OpenStack is an open-source cloud platform that lets companies build, manage, and scale their own cloud infrastructure—without relying on expensive proprietary solutions.

Think of it as LEGO blocks for cloud computing—but instead of plastic bricks, you’re assembling compute, storage, and networking components to create a flexible and powerful cloud. 🧱🚀

‍🤷‍♀️ Why Should You Care?

OpenStack isn’t just another cloud platform—it’s powerful, flexible, and built for the future. Here’s why you should care:

✅ It’s Free & Open-Source – No hefty licensing fees, no vendor lock-in—just pure, community-driven innovation. Whether you’re a student, a startup, or an enterprise, OpenStack gives you the freedom to build your own cloud, your way.

✅ Trusted by Industry Giants – If OpenStack is good enough for NASA, PayPal, and CERN (yes, the guys running the Large Hadron Collider ), it’s definitely worth your time! These tech powerhouses use OpenStack to manage mission-critical workloads, proving its reliability at scale.

✅ Super Scalable – Whether you’re running a tiny home lab or a massive enterprise deployment, OpenStack grows with you. Start with a few nodes and scale to thousands as your needs evolve—without breaking a sweat.

✅ Perfect for Hands-On Learning – Want real-world cloud experience? OpenStack is a playground for learning cloud infrastructure, automation, and networking. Setting up your own OpenStack lab is like a DevOps gym—you’ll gain hands-on skills that are highly valued in the industry.

️🏗️ OpenStack Architecture in Simple Terms – The Avengers of Cloud Computing

OpenStack is a modular system. Think of it as assembling an Avengers team, where each component has a unique superpower, working together to form a powerful cloud infrastructure. Let’s break down the team:

🦾 Nova (Iron Man) – The Compute Powerhouse

Just like Iron Man powers up in his suit, Nova is the core component that spins up and manages virtual machines (VMs) in OpenStack. It ensures your cloud has enough compute power and efficiently allocates resources to different workloads.

• Acts as the brain of OpenStack, managing instances on physical servers.
• Works with different hypervisors like KVM, Xen, and VMware to create VMs.
• Supports auto-scaling, so your applications never run out of power.

️🕸️ Neutron (Spider-Man) – The Web of Connectivity

Neutron is like Spider-Man, ensuring all instances are connected via a complex web of virtual networking. It enables smooth communication between your cloud instances and the outside world.

• Provides network automation, floating IPs, and load balancing.
• Supports custom network configurations like VLANs, VXLAN, and GRE tunnels.
• Just like Spidey’s web shooters, it’s flexible, allowing integration with SDN controllers like Open vSwitch and OVN.

💪 Cinder (Hulk) – The Strength Behind Storage

Cinder is OpenStack’s block storage service, acting like the Hulk’s immense strength, giving persistent storage to VMs. When VMs need extra storage, Cinder delivers!

• Allows you to create, attach, and manage persistent block storage.
• Works with backend storage solutions like Ceph, NetApp, and LVM.
• If a VM is deleted, the data remains safe—just like Hulk’s memory, despite all the smashing.

📸 Glance (Black Widow) – The Memory Keeper

Glance is OpenStack’s image service, storing and managing operating system images, much like how Black Widow remembers every mission.

• Acts as a repository for VM images, including Ubuntu, CentOS, and custom OS images.
• Enables fast booting of instances by storing pre-configured templates.
• Works with storage backends like Swift, Ceph, or NFS.

🔑 Keystone (Nick Fury) – The Security Gatekeeper

Keystone is the authentication and identity service, much like Nick Fury, who ensures that only authorized people (or superheroes) get access to SHIELD.

• Handles user authentication and role-based access control (RBAC).
• Supports multiple authentication methods, including LDAP, OAuth, and SAML.
• Ensures that users and services only access what they are permitted to see.

‍‍🧙‍♂️ Horizon (Doctor Strange) – The All-Seeing Dashboard

Horizon provides a web-based UI for OpenStack, just like Doctor Strange’s ability to see multiple dimensions.

• Gives a graphical interface to manage instances, networks, and storage.
• Allows admins to control the entire OpenStack environment visually.
• Supports multi-user access with dashboards customized for different roles.

🚀 Additional Avengers (Other OpenStack Services)

• Swift (Thor’s Mjolnir) – Object storage, durable and resilient like Thor’s hammer.
• Heat (Wanda Maximoff) – Automates cloud resources like magic.
• Ironic (Vision) – Bare metal provisioning, a bridge between hardware and cloud.

Each of these heroes (services) communicates through APIs, working together to make OpenStack a powerful cloud platform.

apt update &&

️🛠️ How This Helps in Installation

Understanding these services will make it easier to set up OpenStack. During installation, configure each component based on your needs:

• If you need VMs, you focus on Nova, Glance, and Cinder.
• If networking is key, properly configure Neutron.
• Secure access? Keystone is your best friend.

Now that you know the Avengers of OpenStack, you’re ready to start your cloud journey. Let’s get our hands dirty with some real-world OpenStack deployment using Kolla-Ansible.

️🛠️ Hands-on: Deploying OpenStack with Kolla-Ansible

So, you’ve learned the Avengers squad of OpenStack—now it’s time to assemble your own OpenStack cluster! 💪

🔍 Pre-requisites: What You Need Before We Begin

Before we start, let’s make sure you have everything in place:

🖥️ Hardware Requirements (Minimum for a Test Setup)

• 1 Control Node + 1 Compute Node (or more for better scaling).
• At least 8GB RAM, 4 vCPUs, 100GB Disk per node (More = Better).
• Ubuntu 22.04 LTS (Recommended) or CentOS 9 Stream.
• Internet Access (for downloading dependencies).

🔧 Software & Tools Needed

✅ Python 3.10+ – Because Python runs the world.

✅ Ansible 8-9 (ansible-core 2.15-2.16) – Automating OpenStack deployment.

✅ Docker & Docker Compose – Because we’re running OpenStack in containers!

✅ Kolla-Ansible – The magic tool for OpenStack deployment.

Step-by-Step: Setting Up OpenStack with Kolla-Ansible

1️⃣ Set Up Your Environment

First, update your system and install dependencies:

apt update && sudo apt upgrade -y
apt-get install python3-dev libffi-dev gcc libssl-dev python3-selinux python3-setuptools python3-venv -y

apt update && sudo apt upgrade -y
apt-get install python3-dev libffi-dev gcc libssl-dev python3-selinux python3-setuptools python3-venv -y

python3 -m venv kolla-venv
echo "source ~/kolla-venv/bin/activate" >> ~/.bashrc
source ~/kolla-venv/bin/activate

python3 -m venv kolla-venv
echo "source ~/kolla-venv/bin/activate" >> ~/.bashrc
source ~/kolla-venv/bin/activate

Install Ansible & Docker:

sudo apt install python3-pip -y
pip install -U pip
pip install 'ansible-core>=2.15,<2.17' ansible

sudo apt install python3-pip -y
pip install -U pip
pip install 'ansible-core>=2.15,<2.17' ansible

2️⃣ Install Kolla-Ansible

pip install git+https://opendev.org/openstack/kolla-ansible@master

pip install git+https://opendev.org/openstack/kolla-ansible@master

3️⃣ Prepare Configuration Files

Copy default configurations to /etc/kolla:

mkdir -p /etc/kolla
sudo chown $USER:$USER /etc/kolla
cp -r /usr/local/share/kolla-ansible/etc/kolla/* /etc/kolla/

mkdir -p /etc/kolla
sudo chown $USER:$USER /etc/kolla
cp -r /usr/local/share/kolla-ansible/etc/kolla/* /etc/kolla/

Generate passwords for OpenStack services:

kolla-genpwd

kolla-genpwd

Before deploying OpenStack, let’s configure some essential settings in globals.yml. This file defines how OpenStack services are installed and interact with your infrastructure.

Run the following command to edit the file:

nano /etc/kolla/globals.yml

nano /etc/kolla/globals.yml

Here are a few key parameters you must configure:

kolla_base_distro – Defines the OS used for deployment (e.g., ubuntu or centos).

kolla_internal_vip_address – Set this to a free IP in your network. It acts as the virtual IP for OpenStack services. Example: 192.168.1.100.

network_interface – Set this to your main network interface (e.g., eth0). Kolla-Ansible will use this interface for internal communication. (Check using ip -br a)

enable_horizon – Set to yes to enable the OpenStack web dashboard (Horizon).

Once configured, save and exit the file. These settings ensure that OpenStack is properly installed in your environment.

4️⃣ Bootstrap the Nodes (Prepare Servers for Deployment)

kolla-ansible -i /etc/kolla/inventory/all-in-one bootstrap-servers

kolla-ansible -i /etc/kolla/inventory/all-in-one bootstrap-servers

5️⃣ Deploy OpenStack! (The Moment of Truth)

kolla-ansible -i /etc/kolla/inventory/all-in-one deploy

kolla-ansible -i /etc/kolla/inventory/all-in-one deploy

This step takes some time (~30 minutes), so grab some ☕ and let OpenStack build itself.

6️⃣ Access Horizon (Web Dashboard)

Once deployment is complete, check the OpenStack dashboard:

kolla-ansible post-deploy

kolla-ansible post-deploy

Now, find your login details:

cat /etc/kolla/admin-openrc.sh

cat /etc/kolla/admin-openrc.sh

Source the credentials and log in:

source /etc/kolla/admin-openrc.sh
openstack service list

source /etc/kolla/admin-openrc.sh
openstack service list

Open your browser and try accessing: http://<your-server-ip>/dashboard/ or https://<your-server-ip>/dashboard/”

Use the username and the password from admin-openrc.sh.

️ Troubleshooting Common Issues

Deploying OpenStack isn’t always smooth sailing. Here are some common issues and how to fix them:

Kolla-Ansible Fails at Bootstrap

Solution: Run `kolla-ansible -i /etc/kolla/inventory/all-in-one prechecks` to check for missing dependencies before deployment.

Containers Keep Restarting or Failing

Solution: Run docker ps -a | grep Exit to check failed containers. Then inspect logs with:

docker ps --format 'table {{.ID}}\t{{.Names}}\t{{.Status}}'
docker logs $(docker ps -q --filter "status=exited")
journalctl -u docker.service --no-pager | tail -n 50

docker ps --format 'table {{.ID}}\t{{.Names}}\t{{.Status}}'
docker logs $(docker ps -q --filter "status=exited")
journalctl -u docker.service --no-pager | tail -n 50

Horizon Dashboard Not Accessible

Solution: Ensure enable_horizon: yes is set in globals.yml and restart services with:

kolla-ansible -i /etc/kolla/inventory/all-in-one reconfigure

kolla-ansible -i /etc/kolla/inventory/all-in-one reconfigure

Missing OpenStack CLI Commands

Solution: Source the OpenStack credentials file before using the CLI:

source /etc/kolla/admin-openrc.sh

source /etc/kolla/admin-openrc.sh

By tackling these common issues, you’ll have a much smoother OpenStack deployment experience.

🎉 Congratulations, You Now Have Your Own Cloud!

Now that your OpenStack deployment is up and running, you can start launching instances, creating networks, and exploring the endless possibilities.

What’s Next?

✅ Launch your first VM using OpenStack CLI or Horizon!

✅ Set up floating IPs and networks to make instances accessible.

✅ Experiment with Cinder storage and Neutron networking.

✅ Explore Heat for automation and Swift for object storage.

Final Thoughts

Deploying OpenStack manually can be a nightmare, but Kolla-Ansible makes it much easier. You’ve now got your own containerized OpenStack cloud running in no time.