As of early 2026, coding with AI involves interacting with LLM models like a REPL. The difference is that the interaction uses natural language instead of direct code input. New models are launched frequently and it is hard to keep up with the latest releases.

Interface

As far as the customer is concerned, the interface is the product". - Jeff Raskin

For coding, the chat interface is often not sufficient as it can be slow for iterative development. The interaction happens through tools. Currently, the popular options are:

1. New (relatively) IDEs like Cursor, Antigravity with built in AI features

2. Popular IDEs like VS Code, IntelliJ with AI code assist extensions like cline, copilot, etc.

3. AI Tools by AI labs:

   1. Terminal based tool a.k.a cli like Claude Code, Codex, Gemini, etc.

   2. Native Apps

Agents and Security

The tools can be used as a REPL where you interact with the AI or you give it permission to run on its own. These are called Agents. They are autonomous to the extent you allow. Most tools are Agents first now.

The common phases of development are Plan and Act. The planning phase allows you to iterate over the execution plan.

However, the act phase requires giving agents permission to implement, and verify the code. Autonomous software with the capability to run commands and execute code is a security nightmare. To review, and approve every step an agent performs slows down the development cycle. It is increasingly difficult to review the large code changes made by agents in every step. Moreover, they may change course if the approach does not work. Practically, it makes more sense to let the agent run autonomously and review the final result rather than approving each individual step.

What happens if the agent runs the wrong commands and deletes files, or worse, crashes the system. During its attempt to debug an issue, an agent may open ports, disable a security setting or misconfigure the system. We cannot rely on the AI agent implementation to safeguard from such risks. Agents should be prevented from making dangerous operations. This is why they should be run inside a sandbox.

Code Sandboxing

A sandbox is a secure, isolated environment used to execute, test, or analyze code, applications, or programs without affecting the system or surrounding environment.

https://www.browserstack.com/guide/what-is-sandbox

From source code sandboxing :

Sandboxing, in this case, is when a developer limits available system resources to a program from within its source code.

How Popular CLI tools implement sandboxing

Claude Code

They have a great page worth reading: sandboxing

Codex

The code which is implemented in Rust, openai/codex, on a high-level (by platform)

• macOS

  • Uses Apple Seatbelt via sandbox-exec (the CLI wraps commands using Seatbelt).

  • Runs the command inside a mostly read-only jail, exposing a small set of writable roots (cwd, TMPDIR, ~/.codex, etc.).

  • Outbound network is fully blocked by default (even attempted curl will fail).

  • Codex detects sandbox denial via aggregated output (e.g., filesystem "Read-only file system" messages) and special signals.

• Linux

  • There is no built-in OS sandboxing enabled by default in Codex; the README recommends using Docker for deterministic sandboxing.

  • Codex ships/uses a helper binary (codex-linux-sandbox) that combines Landlock and seccomp. The code serializes the SandboxPolicy to JSON and invokes the helper with flags (see landlock.rs and create_linux_sandbox_command_args). The helper enforces file-system and syscall restrictions.

  • The exec path will call spawn_command_under_linux_sandbox when Linux sandboxing is chosen; exec detection also looks for SIGSYS exit codes to infer seccomp denial.

• Windows

  • Codex integrates with a Windows sandboxing component (codex_windows_sandbox). The core crate exposes sandbox_setup_is_complete and run_elevated_setup that call into that module.

  • The code supports a WindowsRestrictedToken sandbox type and includes UI flows for enabling sandbox features, elevated setup, and fallbacks if elevation is declined.

  • Codex also performs world-writable directory scans and shows prompts related to world-writable filesystem protections before enabling agent mode.

Docker Sandbox for Agents

Docker has a neat trick to run agents: docker/sandbox/ which works with the agents. You can get started by docker sandbox run <agent> where can be claude, gemini, codex and more: docker/sandbox-templates

So, why not use Containers everywhere?

Containers are the most widely used sandboxes available today. Running your code inside containers is a solid, straightforward solution. However, containers require a runtime to be installed. While they start quickly, they need images and dependencies downloaded first.

Securing Agents in the IDE

Now that we know that CLI tools implement sandboxing and can also be run inside containers, it feels safer to write code with agents.

However, this begs the question: how do agents running within a typical IDE guarantee safety?

• Relying on the human approval when making changes or running commands

• Approve or Deny List of commands that can be run

• The safety built into the tool/extension itself which may or may not be open-source.

So, you can roll your own solution depending on the isolation level you want:

• Containers (Docker/Podman) for process isolation

• Dedicated user with minimal privileges

• Filesystem restrictions (read-only root, limited workspace)

• Resource limits (memory, CPU, disk quotas)

• Network isolation (if agent doesn't need network) - Not covered here

• Seccomp/AppArmor for syscall filtering - Not covered here

Here are the steps to implement some of the above:

1. Container Based Isolation

Docker/Podman provides strong isolation with minimal overhead:

# Run agent with restricted filesystem access
docker run --rm \\
  --read-only \\                    # Root filesystem is read-only
  --tmpfs /tmp:rw,noexec,nosuid \\  # Temp space without execution
  --volume ./agent_workspace:/workspace:rw \\
  --network none \\                  # No network access
  --cap-drop ALL \\                  # Drop all capabilities
  --security-opt no-new-privileges \\
  agent-image

Benefits: Process isolation, resource limits (CPU, memory), and network control all in one. Bonus this work on Linux and macOS

2. Filesystem Level Restrictions

macOS: Sandbox profiles

For example, Codex uses Seatbelt via on sandbox-exec on macOS. Here’s the step to create a profile

(version 1)
(deny default)
(allow file-read* (subpath "/System/Library"))
(allow file* (subpath "/workspace"))
(allow process-exec (literal "/bin/bash"))

Apply with: sandbox-exec -f profile.sb your-agent-command

More https://igorstechnoclub.com/sandbox-exec/

Linux

There are many Linux tools that can be used, but as you add more steps, it gets closer to a container. Landlock is relatively new and often seen as a superior alternative/complement to traditional syscall filtering mechanisms like seccomp for filesystem control.

chroot + namespaces

# Create isolated environment
mkdir -p /sandbox/{bin,lib,lib64,workspace}
# Copy only necessary binaries
cp /bin/bash /sandbox/bin/
# Copy required libraries (use ldd to find them)
# That can be a bit of work!
# Run agent in chroot jail
sudo chroot /sandbox /bin/bash

unshare for namespace isolation

# Create mount, PID, and network namespaces
unshare --mount --pid --net --fork --user \\
  --map-root-user chroot /sandbox /bin/bash

Caveats

Restricting filesystem access may break tools. For example, uv caches packages on the local system, and if you ask the agent to use uv but (unintentionally) deny access to the .cache directory, it will fail we permission denied error.

3. User Level Isolation

Create a dedicated unprivileged user

# Create restricted user
sudo useradd -m -s /bin/bash -G nogroup aiagent
sudo passwd -l aiagent  # Lock password

# Set up workspace with quotas
sudo mkdir /home/aiagent/workspace
sudo chown aiagent:aiagent /home/aiagent/workspace
sudo chmod 700 /home/aiagent/workspace

# Set disk quota (prevent disk exhaustion)
sudo setquota -u aiagent 1000000 1500000 0 0 /home  # 1GB soft, 1.5GB hard block limit

Run agent as this user:

sudo -u aiagent python agent.py

That’s it for now. Happy Coding!

You ask an AI agent to build a "simple" React component or a Python FastAPI endpoint, and within seconds, it spits out 200 lines of code. It runs, so you commit it.And then the slide begins.

"AI Slop" is the technical debt per second that accumulates when we prioritize velocity over verification. If left unchecked, your repository becomes a digital wasteland where no human understands the "why" behind the code. Here is how you build a high-tech "Safety Net" to stop the slide.

The Strategy

To avoid the slippery slope, you must realize that AI is probabilistic, while quality must be deterministic. You have two choices:

• A. Prompt for Compliance: Ask the AI nicely to follow style guides.

• B. Automated Enforcement: Use tools that physically block the AI from committing "slop."

The Winner? Strategy B. Don't trust the AI to always follow the project’s standards. Instead, use tools to enforce them. By setting up rigorous local gates, you can force the AI to refactor its own output until it meets the bar.

The Safety Net: Pre-commit Arsenal

To keep the "AI Slop" out of main branch, use a multi-layered suite of Pre-commit Hooks. These act as a quality filter that triggers every time code is saved.

We can broadly categories the hooks in three categories, General, Backend, and Frontend. You may add more in the CI/CD pipelines. These are fast tools that can be run locally without slowing the development pace.

General Purpose: The Gatekeepers

These tools protect your infrastructure and prevent the most common "slop" side effects.

• Gitleaks: Scans for hardcoded secrets. AI often "hallucinates" credentials for testing; Gitleaks ensures they never reach the cloud.

• Codespell: Catching typos in documentation and comments that make AI-generated code look unpolished.

• Check-YAML/JSON: Ensures the configuration files hasn't been corrupted by malformed AI output.

Backend: The Modernist

For a modern Python backend, we have:

• Ruff which replaces dozens of legacy tools to lint and format code instantly.

• Pyupgrade: Automatically updates legacy AI code to use modern Python 3.11+ syntax.

• Creosote: finds unused dependencies (dependency bloat)

• pip-audit: finds vulnerable dependencies.

Frontend: The Cleanup Crew

For a React/JS stack:

• Biome is a fast, unified tool for React that prevents the "spaghetti code" found in AI-generated JSX.

• Knip finds “Dead Code”, unused files and exports that AI often leaves behind after a refactor.

The Regression Shield: Baseline Testing

Regression Testing is your real defense against "Functional Slop." AI agents are notorious for "fixing" a bug while unknowingly breaking another core utility.

AI Quality Gate Workflow

1. Ask the AI to generate the feature.

2. Ask the AI to write unit tests for that specific feature. This can a sub-agent too.

3. Run the tests. If they pass, you’ve confirmed the feature works and created a "baseline." If a future AI generation breaks this baseline, you'll know instantly.

4. Iterative Development: The "Git Safety Valve" The fastest way to slide into slop is to commit 1,000 lines of AI changes at once. When the code is that massive, human review becomes impossible. Use Atomic Iterative Commits to stay in control:

   1. Commit 1: Data models and schemas.

   2. Commit 2: Business logic and API endpoints.

   3. Commit 3: UI components and styling. Why? If the AI goes off the rails during the UI phase, you can git rollback or git revert just that specific step. This keeps your history clean and ensures you maintain "quality" while discarding the "cruft."

In case of frontend, you can have a terminal session running npm tests while code is modified.

graph TD

    Start((fa:fa-rocket Start: Feature Request)):::startEnd --> Generate[fa:fa-robot AI Generates Code]
    Generate --> TestGen[fa:fa-vial AI Generates Unit Tests]
    
    subgraph QualityGate [fa:fa-shield-halved Automated Quality Gate]
        direction TB
        RunHooks[fa:fa-terminal Run: Pre-commit Hooks]:::process
        RunTests[fa:fa-microscope Run: Test Suite]:::process
        
        RunHooks --> HookCheck{Hooks Pass?}:::decision
        HookCheck -- "No" --> FixHooks[fa:fa-wrench AI Fixes Linting/Security]:::error
        FixHooks --> RunHooks
        
        HookCheck -- "Yes" --> RunTests
        RunTests --> TestCheck{Tests Pass?}:::decision
        TestCheck -- "No" --> FixTests[fa:fa-bug AI Fixes Logic/Regressions]:::error
        FixTests --> RunTests
    end

    TestGen --> RunHooks
    TestCheck -- "Yes" --> AtomicCommit[fa:fa-eye Human Review: Atomic Commit]:::decision
    
    %% Review Loop
    AtomicCommit -- "Changes Requested" --> Generate

    subgraph GitStrategy [fa:fa-code-branch Iterative Git Valve]
        direction TB
        Step1[fa:fa-database Commit 1: Models/Schemas]:::action
        Step2[fa:fa-gears Commit 2: Logic/Endpoints]:::action
        Step3[fa:fa-desktop Commit 3: UI/Styling]:::action
        
        Step1 --> Step2
        Step2 --> Step3
    end

    AtomicCommit -- "Approved" --> Step1

    Step3 --> Success((fa:fa-check-circle End Feature)):::startEnd
    
    %% The Development Cycle
    Success -. "Next Iteration" .-> Start

How to use with AI Agents

To ensure the highest code quality when working with AI:

1. Instruction: Tell the agent: "Run pre-commit run --all-files before committing.” Bonus: “Generate meaningful git commit” Please note that this may consume additional credits.

2. Context: Ensure the agent has read the .pre-commit-config.yaml so it understands the rules it must follow (e.g., using Ruff instead of Black).

3. Resolution: If a tool fails, provide the error log back to the AI and ask it to fix the specific violations.

"AI Slop" is the natural result of friction-less code generation. By using a deterministic toolchain of pre-commit hooks and a disciplined, iterative Git workflow, you can move at the speed of AI while maintaining the quality of a veteran architect.

Here's a sample pre-commit hook for a React (Vite) project: .pre-commit-config.yaml

Run the pre-commit on all files using pre-commit run --all-files which assumes pre-commit is installed. if you use uv , which is highly recommended, you can do uvx pre-commit

Caveats

• Static analysis can give false positives. You may have to ignore some failures, especially spell checks. Configure the tool to ignore specific files, e.g. package.json.

• Dependency management can be tricky. Development and test packages increase the distribution size if not separated clearly. Each package manager has its own solution to this problem, so be careful when adding dependencies.

Happy coding!

Writing effective FIO (Flexible I/O Tester) jobs can be a complex and error-prone process, especially for developers and system administrators who need to benchmark storage performance across different platforms and I/O engines. The challenges range from understanding the myriad of configuration options to ensuring cross-platform compatibility and avoiding dangerous configurations that could lead to data loss.

The Core Challenges of FIO Job Configuration

1. Complexity of FIO Options

FIO provides hundreds of configuration options that can be overwhelming for both beginners and experienced users:

• I/O Type Options: rw, rwmixread, and other parameters control read/write patterns
• Block Size Configuration: bs, bsrange for controlling I/O unit sizes
• I/O Engine Selection: Different engines like libaio, posixaio, io_uring have platform-specific requirements
• Target Specification: filename, directory, and related options for defining test targets
• Threading and Synchronization: numjobs, group_reporting, stonewall for parallel execution
• Verification and Logging: Extensive options for data integrity checking and performance logging

The sheer volume of options makes it difficult to remember syntax, understand interactions between parameters, and ensure proper configuration.

2. Platform-Specific Compatibility Issues

FIO jobs must account for significant differences between operating systems:

• Linux: Supports advanced engines like libaio, io_uring, splice
• Windows: Limited to windowsaio
• macOS: Supports posixaio, mmap, but lacks some Linux-specific engines

Using an incompatible I/O engine on a platform can cause job failures or unexpected behavior.

3. Dangerous Configuration Risks

Improper FIO configurations can lead to catastrophic data loss:

• Raw Device Writes: Accidentally writing to /dev/sdX or similar block devices destroys data
• Missing Targets: Forgetting to specify filename or directory causes job failures
• Engine-Specific Requirements: Some engines like libaio require direct=1 for proper operation
• Privilege Issues: Certain operations require root/sudo access

4. Validation and Error Prevention

Manual FIO job writing lacks real-time validation:

• No immediate feedback on configuration errors
• Easy to miss critical warnings about data-destructive operations
• Difficult to catch platform incompatibilities before execution
• No automated checking of option combinations that might conflict

5. Job Organization and Management

Managing multiple FIO jobs becomes cumbersome:

• Difficult to organize global vs. per-job options
• No visual interface for comparing different job configurations
• Manual editing of .fio files is error-prone and time-consuming
• Lack of version control or easy modification tracking

How fioJobBuilder Addresses These Challenges

fioJobBuilder is a configuration tool that helps with these FIO job writing challenges:

1. Interactive Visual Interface

Instead of manually editing text files, fioJobBuilder provides:

• Organized Option Categories: Options grouped by usage type (Block, File, Others) and functional categories
• Searchable Documentation Links: Each option includes direct links to official FIO documentation
• Platform-Specific Filtering: Automatically shows only relevant options for the selected platform
• Real-time Preview: Live generation of the .fio file as you configure options

2. Cross-Platform Compatibility Handling

The tool intelligently manages platform differences:

• Platform Toggle: Easy switching between Linux, Windows, and macOS
• Engine Filtering: Only shows compatible I/O engines for the selected platform
• Platform-Specific Validation: Warns about engine/platform mismatches
• Automatic Adjustments: Handles platform-specific requirements automatically

3. Comprehensive Validation System

fioJobBuilder includes multiple layers of validation:

Static Validation

• Target Checking: Ensures filename or directory is specified
• Engine Validation: Verifies engine compatibility with selected platform
• Dangerous Operation Warnings: Flags raw device writes (/dev/*) in write mode
• Engine-Specific Requirements: Checks for required options like direct=1 with libaio

AI-Powered Analysis (Optional)

• Configuration Scoring: Rates your job configuration from 0-100
• Performance Suggestions: Provides optimization recommendations
• Risk Assessment: Identifies potential issues before execution
• Best Practice Guidance: Suggests improvements based on FIO expertise

4. Job Management Features

The tool provides robust job organization capabilities:

• Global vs. Per-Job Options: Clear separation with visual indicators
• Multiple Job Support: Create and manage multiple jobs in one configuration
• Job Cloning: Easy duplication of existing jobs for variation testing
• Reset Capabilities: Quickly clear configurations and start fresh

5. Safety Features

fioJobBuilder prioritizes preventing dangerous operations:

• Critical Warning System: Highlights data-destructive operations in red
• Platform Compatibility Checks: Prevents using incompatible engines
• Target Validation: Ensures jobs have proper targets before execution
• Visual Feedback: Clear color-coded warnings and error indicators

Practical Examples

Example 1: Creating a Safe Block Device Test

Challenge: You want to test a block device but need to ensure you don't accidentally overwrite important data.

Solution with fioJobBuilder:

1. Select Linux platform
2. Choose Block usage type
3. Set rw=randwrite for random write testing
4. Specify target as /dev/nvme0n1 (test device)
5. The validation panel immediately shows: "CRITICAL WARNING - Writing to raw device '/dev/nvme0n1' will destroy data"
6. You can then confirm this is your intended test device

Example 2: Cross-Platform Configuration

Challenge: You need to create jobs that work on both Linux and Windows.

Solution with fioJobBuilder:

1. Start with Linux platform, configure using libaio engine
2. Switch to Windows platform - the tool automatically:
   • Changes available engines to Windows-compatible ones
   • Shows warning about libaio incompatibility
   • Suggests using windowsaio instead
3. Adjust configuration for Windows compatibility
4. Export separate configurations for each platform

Example 3: Complex Multi-Job Benchmarking

Challenge: You need to run multiple different workloads simultaneously.

Solution with fioJobBuilder:

1. Create a global configuration with common settings
2. Add multiple jobs with different rw patterns
3. Each job inherits global settings but can override specific options
4. Visual interface shows all jobs clearly organized
5. Single export generates complete multi-job configuration

Technical Implementation

fioJobBuilder is built with modern web technologies:

• React + TypeScript: Provides responsive UI with type safety
• Vite: Fast development and production builds
• Tailwind CSS: Clean, modern styling
• Google Gemini API: Optional AI analysis integration

The architecture includes:

• State Management: React hooks for managing complex configuration state
• Validation Engine: Comprehensive rule-based checking system
• Platform Detection: Automatic adjustment of available options
• Export System: Clean .fio file generation with syntax highlighting

Conclusion

Writing FIO jobs doesn't have to be a daunting, error-prone process. fioJobBuilder addresses the core challenges by providing:

1. Simplified Configuration: Visual interface instead of manual text editing
2. Cross-Platform Intelligence: Automatic handling of platform differences
3. Comprehensive Validation: Multiple layers of error checking
4. Enhanced Safety: Protection against dangerous operations
5. Advanced Features: AI analysis, job management, and organization tools

By using fioJobBuilder, developers and system administrators can focus on their benchmarking goals rather than struggling with configuration syntax and compatibility issues. The tool significantly reduces the learning curve for FIO while providing expert-level validation and optimization capabilities.

Getting Started

To try fioJobBuilder:

git clone https://github.com/rainzoo/fio-job-builder.git
cd fio-job-builder
npm install
npm run dev

Then open http://localhost:5173 in your browser and start building FIO jobs with confidence!

References

• FIO Official Documentation
• FIO GitHub Repository
• fioJobBuilder Source Code

The Use Case

We'll examine how to handle user account parameters across different contexts:

• username: The account identifier

• address: Physical or mailing address

• phone: Contact phone number

• email: Email address

Python: Function Arguments and Environment Variables

Python offers multiple approaches to parameter handling. The most straightforward method uses function arguments with type hints and default values:

# user_manager.py
import sys
import os

def create_user(username: str, email: str, address: str = "", phone: str = "") -> dict:
    """
    Create a user account with the provided parameters.

    Args:
        username: Required username for the account
        email: Required email address
        address: Optional physical address
        phone: Optional phone number

    Returns:
        Dictionary containing user details
    """
    user_data = {
        "username": username,
        "email": email,
        "address": address if address else "Not provided",
        "phone": phone if phone else "Not provided"
    }

    print(f"Creating user account:")
    for key, value in user_data.items():
        print(f"  {key}: {value}")

    return user_data

def main():
    # Method 1: Command-line arguments
    if len(sys.argv) >= 3:
        username = sys.argv[1]
        email = sys.argv[2]
        address = sys.argv[3] if len(sys.argv) > 3 else ""
        phone = sys.argv[4] if len(sys.argv) > 4 else ""
    else:
        # Method 2: Environment variables as fallback
        username = os.getenv("USERNAME", "default_user")
        email = os.getenv("EMAIL", "user@example.com")
        address = os.getenv("ADDRESS", "")
        phone = os.getenv("PHONE", "")

    create_user(username, email, address, phone)

if __name__ == "__main__":
    main()

Python's flexibility allows you to combine multiple parameter sources, with command-line arguments taking precedence over environment variables.

The standard library has argparse, and whole page for choosing an argument parser. There are excellent packages to create CLIs like typer and click.

Bash: Positional Parameters and Named Variables

Bash scripts use positional parameters and can validate their presence before execution:

#!/bin/bash
# create_user.sh

# Function to create user with parameters
create_user() {
    local username=$1
    local email=$2
    local address=${3:-"Not provided"}
    local phone=${4:-"Not provided"}

    echo "Creating user account:"
    echo "  username: $username"
    echo "  email: $email"
    echo "  address: $address"
    echo "  phone: $phone"

    # Simulate user creation
    echo "User account created successfully"
}

# Validate required parameters
if [ $# -lt 2 ]; then
    echo "Error: Missing required parameters"
    echo "Usage: $0 <username> <email> [address] [phone]"
    exit 1
fi

# Extract parameters
USERNAME=$1
EMAIL=$2
ADDRESS=${3:-""}
PHONE=${4:-""}

# Call the function
create_user "$USERNAME" "$EMAIL" "$ADDRESS" "$PHONE"

The ${variable:-default} syntax provides a clean way to specify default values for optional parameters.

Dockerfile: Build Arguments and Environment Variables

Dockerfiles distinguish between build-time arguments (ARG) and runtime environment variables (ENV):

# Dockerfile
FROM python:3.9-slim

# Build-time arguments with defaults
ARG APP_VERSION=1.0.0
ARG PYTHON_ENV=production

# Set environment variables for runtime
ENV USERNAME=""
ENV EMAIL=""
ENV ADDRESS=""
ENV PHONE=""

# Create application directory
WORKDIR /app

# Copy application files
COPY user_manager.py .
COPY create_user.sh .

# Make bash script executable
RUN chmod +x create_user.sh

# Install any required packages
RUN pip install --no-cache-dir --upgrade pip

# Default command
CMD ["python", "user_manager.py"]

You can override these at build time:

docker build --build-arg APP_VERSION=2.0.0 -t user-manager .

And at runtime:

docker run -e USERNAME="jdoe" -e EMAIL="jdoe@example.com" user-manager

Jenkinsfile: Declarative Pipeline Parameters

Jenkins pipelines provide a structured approach to parameter handling through the parameters directive:

pipeline {
    agent any

    parameters {
        string(
            name: 'USERNAME',
            defaultValue: 'testuser',
            description: 'Username for the account',
            trim: true
        )
        string(
            name: 'EMAIL',
            defaultValue: 'test@example.com',
            description: 'Email address',
            trim: true
        )
        string(
            name: 'ADDRESS',
            defaultValue: '',
            description: 'Physical address (optional)',
            trim: true
        )
        string(
            name: 'PHONE',
            defaultValue: '',
            description: 'Phone number (optional)',
            trim: true
        )
        choice(
            name: 'EXECUTION_MODE',
            choices: ['python', 'bash', 'docker'],
            description: 'Which implementation to execute'
        )
    }

    environment {
        SCRIPT_DIR = "${WORKSPACE}"
    }

    stages {
        stage('Validate Parameters') {
            steps {
                script {
                    echo "Validating parameters..."

                    if (params.USERNAME.isEmpty()) {
                        error("USERNAME parameter is required")
                    }

                    if (params.EMAIL.isEmpty()) {
                        error("EMAIL parameter is required")
                    }

                    // Basic email validation
                    if (!params.EMAIL.contains('@')) {
                        error("EMAIL must be a valid email address")
                    }

                    echo "Parameter validation passed"
                }
            }
        }

        stage('Display Parameters') {
            steps {
                echo "Received parameters:"
                echo "  Username: ${params.USERNAME}"
                echo "  Email: ${params.EMAIL}"
                echo "  Address: ${params.ADDRESS ?: 'Not provided'}"
                echo "  Phone: ${params.PHONE ?: 'Not provided'}"
                echo "  Execution Mode: ${params.EXECUTION_MODE}"
            }
        }

        stage('Execute Python Script') {
            when {
                expression { params.EXECUTION_MODE == 'python' }
            }
            steps {
                script {
                    echo "Executing Python implementation..."
                    sh """
                        python3 user_manager.py \
                            '${params.USERNAME}' \
                            '${params.EMAIL}' \
                            '${params.ADDRESS}' \
                            '${params.PHONE}'
                    """
                }
            }
        }

        stage('Execute Bash Script') {
            when {
                expression { params.EXECUTION_MODE == 'bash' }
            }
            steps {
                script {
                    echo "Executing Bash implementation..."
                    sh """
                        chmod +x create_user.sh
                        ./create_user.sh \
                            '${params.USERNAME}' \
                            '${params.EMAIL}' \
                            '${params.ADDRESS}' \
                            '${params.PHONE}'
                    """
                }
            }
        }

        stage('Execute Docker Container') {
            when {
                expression { params.EXECUTION_MODE == 'docker' }
            }
            steps {
                script {
                    echo "Building and executing Docker implementation..."
                    sh """
                        docker build -t user-manager:latest .
                        docker run --rm \
                            -e USERNAME='${params.USERNAME}' \
                            -e EMAIL='${params.EMAIL}' \
                            -e ADDRESS='${params.ADDRESS}' \
                            -e PHONE='${params.PHONE}' \
                            user-manager:latest
                    """
                }
            }
        }

        stage('Report Results') {
            steps {
                script {
                    echo "User account creation process completed"
                    echo "Summary:"
                    echo "  Method used: ${params.EXECUTION_MODE}"
                    echo "  Account created for: ${params.USERNAME}"
                }
            }
        }
    }

    post {
        success {
            echo "Pipeline completed successfully"
        }
        failure {
            echo "Pipeline failed - check logs for details"
        }
        always {
            cleanWs()
        }
    }
}

Takeaways

Each language and tool offers distinct advantages for parameter handling:

Python excels at combining multiple parameter sources with clear type hints and validation. The language's flexibility makes it ideal for complex parameter processing logic.

Bash provides straightforward positional parameters with simple default value syntax. It's particularly effective for system-level scripting where parameters flow directly from command invocation.

Dockerfile separates build-time configuration (ARG) from runtime configuration (ENV), enabling flexible container deployment strategies across different environments.

Jenkins offers a declarative, UI-friendly approach to parameters with built-in validation and type safety. The parameters directive creates an intuitive interface for operators while maintaining programmatic access in pipeline code.

Best Practices

1. Always validate required parameters before processing begins

2. Provide sensible defaults for optional parameters

3. Document parameter purposes through comments or descriptions

4. Use consistent naming conventions across all implementations

5. Escape parameters properly when passing between systems to prevent injection vulnerabilities

6. Consider parameter sensitivity and avoid logging credentials or personal information

Arger

By understanding how each tool handles parameters, you can build robust automation workflows that adapt to different execution contexts while maintaining consistency and reliability.

However, it can be a pain to write the boilerplate code, especially when you change the parameters. Updating the same across the entire pipeline can get boring quick. So, I created an app to generate the code using Opal.

It takes two inputs:

1. Parameter name and type

2. Languages to generate the code, like Python, Bash, Jenkinsfile, and Dockerfile.

Then, it will generate the code required to handle these parameters. Here’s the link:

Arger

"Arger" can refer to the German word "Ärger," which means "annoyance," "irritation," or "trouble". It can also refer to the German verb "ärgern," which means "to annoy," "to irritate," or "to anger". Less commonly, "Arger" might be a surname or a personal name of various origins.

Have you ever wanted to learn how to debug complex software systems in a safe and controlled environment? Introducing FauxFS, a mock file system written in Python, designed specifically for educational purposes. But here's the twist: FauxFS is riddled with intentional bugs, providing a unique and challenging learning experience for aspiring software engineers and seasoned developers alike.

What is FauxFS?

FauxFS is an in-memory mock file system that simulates the behavior of a real file system. It comes with basic features you'd expect:

• Files and Directories: Create, delete, and manage files and directories.

• Permissions: A Unix-like permission system with owner, group, and other read/write/execute permissions.

• Interactive Shell: A command-line interface to interact with the file system using familiar commands like ls, cd, mkdir, rm, and more.

You can create files, write content to them, organize them into directories, and manage their permissions, just like you would on a regular file system.

The Twist: Intentional Bugs

What sets FauxFS apart is its collection of 22 intentional bugs. These aren't accidental mistakes; they are carefully crafted flaws designed to mimic real-world software defects. The bugs are categorized into three difficulty levels:

• Beginner: Simple issues like off-by-one errors and case sensitivity problems.

• Intermediate: More complex bugs like race conditions and path traversal vulnerabilities.

• Advanced: Deeply embedded issues such as deadlocks and integer overflows.

The goal isn't to have a perfect file system but to provide a playground for developers to hunt for and understand these bugs.

Why Learn with Bugs?

In the real world, software has bugs. Learning to find, understand, and fix them is a critical skill for any software engineer. FauxFS provides a safe environment to develop these skills without the risk of breaking a production system. By working with FauxFS, you will learn to:

• Debug Filesystem Operations: Understand the common pitfalls in file system design and implementation.

• Identify Memory Issues: Learn to spot memory leaks and buffer overflows.

• Recognize Concurrency Problems: Get hands-on experience with race conditions and deadlocks.

• Understand Security Vulnerabilities: Discover how permission systems can be bypassed.

• Practice Systematic Debugging: Use tests, logging, and other tools to systematically hunt for bugs.

Getting Started

Getting started with FauxFS is easy. All you need is Python 3.13 or higher.

1. Clone the repository:

    git clone https://github.com/rainzoo/fauxfs.git
    cd fauxfs
   

2. Build and run interactive container

docker build -t fauxfs:interactive .
docker run -it --rm fauxfs:interactive

Once you're in the FauxFS shell, you can start exploring the file system and hunting for bugs. Try running the test suite to see which tests fail, or experiment with edge cases to uncover hidden issues.

FauxFS is a learning tool that turns debugging into a fun and educational challenge. Whether you're a student learning about operating systems or a developer looking to sharpen your debugging skills, FauxFS offers a unique and valuable experience.

So, are you ready to go bug hunting? Clone the FauxFS repository and start exploring today! Refer to the docs directory for more instructions:

Have you ever found yourself debugging a system issue and wished you had a quick way to view all the important OS configuration limits and system information in one place?

Meet Limits: an elegant Python terminal application that provides exactly that functionality with a clean, interactive interface. Limits is a lightweight Python terminal application built with the Textual framework that displays comprehensive OS configuration and limits information. It's designed to be a debugging companion for developers and system administrators who need quick access to system resource information.

Getting Started

Ensure you have Python 3.13+ and uv installed

• Clone the repository from https://github.com/rainzoo/limits

• Run: uv run limits.py (thanks to PEP 723)

• Navigate with arrow keys, press r to refresh, q to quit

🖥️ Basic System Info

The application displays a wide range of system metrics organized into logical sections:

• CPU Information: Physical and logical core counts

• Memory Information: Total RAM, available memory, and swap space

• Process Resource Limits: File descriptors, stack size, process limits, virtual memory, and CPU time constraints

• Filesystem Limits: Maximum filename and path lengths

• Mounted Filesystems: Disk usage and inode information for all mounted drives

⚡ Alternative Usage

The application can be run in multiple ways:

# With dependency management
uv sync
uv run limits.py

# Debug mode (with textual-dev)
textual run limits.py

# Docker 
docker build -f Dockerfile -t limits:latest .
docker run -it limits:latest

Dependencies

Dependencies are listed in pyproject.toml:

• Textual: Powers the terminal user interface

  • A clean, tabular display with zebra striping for easy reading

  • Interactive navigation with cursor support

  • Real-time refresh capability

• psutil: Cross-platform system and process utilities

• humanize: Makes numbers and dates more human-readable

The application intelligently handles platform differences, providing detailed resource limit information on POSIX systems (Linux, macOS) while gracefully degrading on Windows.

The get_os_info() gathers CPU topology and capabilities, Memory hierarchy (RAM, swap), Process resource constraints, Filesystem characteristics, and Storage device information.

This is an interesting demo whether you're a system administrator looking for a quick diagnostic tool, a developer debugging resource issues, or a Python enthusiast interested in terminal UI development.

Deep Dive

Understating these limits is vital for building robust and performant applications.

1. CPU Information

Physical & Logical Cores

• Concurrency: The number of cores determines the true level of parallelism an application can achieve. For CPU-bound tasks, this number is critical for tuning thread pools or multiprocessing strategies to maximize performance without causing excessive context switching.

• Performance Tuning: Knowing the core count helps developers design efficient parallel algorithms and decide on the optimal number of worker processes or threads for services like web servers or data processing jobs.

2. Process Resource Limits

These are per-process limits, often configured at the OS level to ensure system stability by preventing any single process from consuming all available resources.

Max Open Files

This is one of the most common limits hit by network services and database applications. Servers that handle many simultaneous connections (e.g., web servers, message queues) or applications that access many files can easily exhaust this limit, leading to "Too many open files" errors. Developers must monitor this and design their code to manage file descriptors efficiently (e.g., using connection pools).

Max Processes

This limit affects applications that use a multiprocess architecture (e.g., preforking web servers like older versions of Apache or Gunicorn). Exceeding the user's process limit will prevent the application from scaling out by creating new child processes, leading to service degradation.

Stack Size

This defines the amount of memory allocated for a thread's function call stack. Applications with deep recursion or large stack-allocated variables can exceed this limit, causing a stack overflow and an immediate crash. It's a critical consideration for system programmers writing recursive algorithms or complex function call chains.

Virtual Memory (Address Space)

This limits the total virtual memory a process can request. For memory-intensive applications like in-memory databases, caches, or scientific computing tools, this limit can be a bottleneck. Hitting it can cause allocation failures, even if physical RAM is available.

CPU Time Limit

This is a safeguard that kills a process after it has consumed a certain amount of CPU time. While less common in general app development, it's important in multi-user or high-performance computing (HPC) environments to prevent runaway processes from monopolizing CPU resources.

3. Filesystem and Storage Limits

Max Filename & Path Length

Applications that create or manage user-defined file structures must respect these limits to ensure cross-platform compatibility and prevent ENOENT (No such file or directory) or ENAMETOOLONG errors. This is especially important for applications that generate nested directory structures or long, descriptive filenames.

Disk & Inode Usage

• Disk Space : Running out of disk space is a common cause of application failure. Applications that write logs, temporary files, or store data must have error handling for disk-full scenarios.

• Inodes : An inode is a data structure that stores information about a file. It's possible to run out of inodes even if disk space is available, especially on systems with a large number of very small files (e.g., mail servers, caches). Applications that create many small files must be aware of this potential limit.

Curious Case of Container Limits

In containers, these are among the most important limits:

• CPU Limits (Shares, Quota, Period) These control how much CPU time a container gets. Shares provide a relative weight, while quota/period provide a hard cap (e.g., "use 2 CPU cores worth of time every 100ms"). Prevents a single "noisy neighbor" container from starving others of CPU. It's fundamental for multi-tenancy and ensuring predictable performance, but setting limits too low can artificially throttle an application that needs to burst.

• Memory Limit (memory.limit_in_bytes) The absolute maximum amount of memory a container can use. This is the most critical limit for container stability. If a container's memory usage exceeds this limit, the kernel's Out-Of-Memory (OOM) killer will immediately terminate a process inside it (often the main application), causing the container to crash. Application developers must be acutely aware of their memory footprint relative to this limit.

You run the app with the following options to limit cpu or memory using the Dockerfile :

• docker run --cpus 4 -it limits:latest or docker run --memory 4g -it limits:latest

Why? The data that is displayed is from the host system. In my case, I have assigned 8 Gb memory and 8 CPUs to my docker engine. This is not what the container is using.

What is the way to fix this? This is left as an exercise for the reader.

This is part of the Distributed Storage series. We assume you have a Kubernetes cluster running as described in Kubernetes With Microk8s. Using the same virtual machines, we have deployed a Ceph cluster and enabled different types of storage: file, object, and block (default). This ensures that we have covered the prerequisites.

Rook is an open source cloud-native storage orchestrator, providing the platform, framework, and support for Ceph storage to natively integrate with cloud-native environments. The storage architecture is well documented. We focus on getting it up and running.

Enable Rook

First, we enable rook on the k8s cluster

manas@manas-s01:~$ sudo microk8s enable rook-ceph
Infer repository core for addon rook-ceph
Add Rook Helm repository <https://charts.rook.io/release>
"rook-release" has been added to your repositories
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "rook-release" chart repository
Update Complete. ⎈Happy Helming!⎈
Install Rook version v1.11.9
NAME: rook-ceph
LAST DEPLOYED: Fri Jun 13 16:01:21 2025
NAMESPACE: rook-ceph
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The Rook Operator has been installed. Check its status by running:
  kubectl --namespace rook-ceph get pods -l "app=rook-ceph-operator"
...

Check Rook Status

manas@manas-s01:~$ microk8s kubectl --namespace rook-ceph get pods -l "app=rook-ceph-operator"
NAME                                  READY   STATUS    RESTARTS   AGE
rook-ceph-operator-684bbd569f-82dv9   1/1     Running   0          30m

Connect Ceph and k8s cluster

manas@manas-s01:~$ sudo microk8s connect-external-ceph
[sudo] password for manas: 
Looking for MicroCeph on the host
Detected existing MicroCeph installation
Attempting to connect to Ceph cluster
Successfully connected to e43d58a8-deb0-43d9-b7ef-d6159f114c02 (192.168.148.134:0/1580887393)
Creating pool microk8s-rbd0 in Ceph cluster
Configuring pool microk8s-rbd0 for RBD
Successfully configured pool microk8s-rbd0 for RBD
Creating namespace rook-ceph-external
namespace/rook-ceph-external created
Configuring Ceph CSI secrets
Successfully configured Ceph CSI secrets
Importing Ceph CSI secrets into MicroK8s
secret/rook-ceph-mon created
configmap/rook-ceph-mon-endpoints created
secret/rook-csi-rbd-node created
secret/rook-csi-rbd-provisioner created
storageclass.storage.k8s.io/ceph-rbd created
Importing external Ceph cluster
W0613 16:32:46.334927  129114 warnings.go:70] unknown field "spec.upgradeOSDRequiresHealthyPGs"
NAME: rook-ceph-external
LAST DEPLOYED: Fri Jun 13 16:32:45 2025
NAMESPACE: rook-ceph-external
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The Ceph Cluster has been installed. Check its status by running:
  kubectl --namespace rook-ceph-external get cephcluster

Visit <https://rook.io/docs/rook/latest/CRDs/Cluster/ceph-cluster-crd/> for more information about the Ceph CRD.

Important Notes:
- You can only deploy a single cluster per namespace
- If you wish to delete this cluster and start fresh, you will also have to wipe the OSD disks using `sfdisk`

=================================================

Successfully imported external Ceph cluster. You can now use the following storageclass
to provision PersistentVolumes using Ceph CSI:

NAME       PROVISIONER                  RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
ceph-rbd   rook-ceph.rbd.csi.ceph.com   Delete          Immediate           true                   2s

Check Ceph cluster status

# Initial 
manas@manas-s01:~$ microk8s kubectl --namespace rook-ceph-external get cephcluster
NAME                 DATADIRHOSTPATH   MONCOUNT   AGE   PHASE   MESSAGE   HEALTH   EXTERNAL   FSID
rook-ceph-external   /var/lib/rook     3          67s                              true       
# Final
manas@manas-s01:~$ microk8s kubectl --namespace rook-ceph-external get cephcluster
NAME                 DATADIRHOSTPATH   MONCOUNT   AGE    PHASE       MESSAGE                          HEALTH      EXTERNAL   FSID
rook-ceph-external   /var/lib/rook     3          6m1s   Connected   Cluster connected successfully   HEALTH_OK   true       e43d58a8-deb0-43d9-b7ef-d6159f114c02
ma

Wait until all k8s resources are in Running status:

manas@manas-s01:~$ microk8s kubectl get all --namespace rook-ceph
NAME                                                READY   STATUS    RESTARTS   AGE
pod/csi-cephfsplugin-chz2w                          2/2     Running   0          5m7s
pod/csi-cephfsplugin-n2wxd                          2/2     Running   0          5m7s
pod/csi-cephfsplugin-provisioner-7bd8fb7c64-fbmw6   5/5     Running   0          5m7s
pod/csi-cephfsplugin-provisioner-7bd8fb7c64-tbqlp   5/5     Running   0          5m7s
pod/csi-cephfsplugin-zpltk                          2/2     Running   0          5m7s
pod/csi-rbdplugin-7dgxz                             2/2     Running   0          5m7s
pod/csi-rbdplugin-8x5x7                             2/2     Running   0          5m7s
pod/csi-rbdplugin-provisioner-5f7d95b6fb-s4znf      5/5     Running   0          5m7s
pod/csi-rbdplugin-provisioner-5f7d95b6fb-wjk7q      5/5     Running   0          5m7s
pod/csi-rbdplugin-zccc7                             2/2     Running   0          5m7s
pod/rook-ceph-operator-684bbd569f-82dv9             1/1     Running   0          39m

NAME                              DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/csi-cephfsplugin   3         3         3       3            3           <none>          5m7s
daemonset.apps/csi-rbdplugin      3         3         3       3            3           <none>          5m8s

NAME                                           READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/csi-cephfsplugin-provisioner   2/2     2            2           5m7s
deployment.apps/csi-rbdplugin-provisioner      2/2     2            2           5m7s
deployment.apps/rook-ceph-operator             1/1     1            1           39m

NAME                                                      DESIRED   CURRENT   READY   AGE
replicaset.apps/csi-cephfsplugin-provisioner-7bd8fb7c64   2         2         2       5m7s
replicaset.apps/csi-rbdplugin-provisioner-5f7d95b6fb      2         2         2       5m7s
replicaset.apps/rook-ceph-operator-684bbd569f             1         1         1       39m
manas@manas-s01:~$

Meanwhile, If you want to explore the possible API Resources, you the following command:

manas@manas-s01:~$ microk8s kubectl api-resources --namespace rook-ceph-external | grep ceph
cephblockpoolradosnamespaces                          ceph.rook.io/v1                   true         CephBlockPoolRadosNamespace
cephblockpools                                        ceph.rook.io/v1                   true         CephBlockPool
cephbucketnotifications                               ceph.rook.io/v1                   true         CephBucketNotification
cephbuckettopics                                      ceph.rook.io/v1                   true         CephBucketTopic
cephclients                                           ceph.rook.io/v1                   true         CephClient
cephclusters                                          ceph.rook.io/v1                   true         CephCluster
cephfilesystemmirrors                                 ceph.rook.io/v1                   true         CephFilesystemMirror
cephfilesystems                                       ceph.rook.io/v1                   true         CephFilesystem
cephfilesystemsubvolumegroups                         ceph.rook.io/v1                   true         CephFilesystemSubVolumeGroup
cephnfses                           nfs               ceph.rook.io/v1                   true         CephNFS
cephobjectrealms                                      ceph.rook.io/v1                   true         CephObjectRealm
cephobjectstores                                      ceph.rook.io/v1                   true         CephObjectStore
cephobjectstoreusers                rcou,objectuser   ceph.rook.io/v1                   true         CephObjectStoreUser
cephobjectzonegroups                                  ceph.rook.io/v1                   true         CephObjectZoneGroup
cephobjectzones                                       ceph.rook.io/v1                   true         CephObjectZone
cephrbdmirrors                                        ceph.rook.io/v1                   true         CephRBDMirror

To see Block storage status, you can use cephblockpools. Similarly, cephobjectstores is for Object and cephnfses is for NFS.

Refer to examples from https://github.com/rook/rook/tree/master/deploy/examples

Create Block Storage

$ microk8s kubectl create -f storageClass.yaml 
cephblockpool.ceph.rook.io/replicapool created
storageclass.storage.k8s.io/rook-ceph-block created

$ microk8s kubectl -n rook-ceph get cephblockpools
NAME          PHASE
replicapool   Progressing

$ microk8s kubectl create -f mysql.yaml 
service/wordpress-mysql created
persistentvolumeclaim/mysql-pv-claim created
deployment.apps/wordpress-mysql created

Create Object Stores

This requires rgw that we have already enabled

$ kubectl create -f object.yaml

$ microk8s kubectl -n rook-ceph get cephobjectstores
NAME       PHASE
my-store   Progressing

Create Share File Systems

$ kubectl create -f file.yaml
$ microk8s kubectl get cephfilesystems -n rook-ceph
NAME   ACTIVEMDS   AGE     PHASE
myfs   1           5m38s   Progressing

That’s it! We have completed deploying a cloud native storage solution, that too, locally.

This is part of the Distributed Storage series. We assume you have a Kubernetes cluster running as described in Kubernetes With Microk8s. Using the same virtual machines, we will deploy a Ceph cluster and enable different types of storage: file, object, and block (default).

Prerequisites

It is worth repeating that each VM has a disk which can be consumed by Ceph:

$ lsblk | grep -v loop
NAME                      MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sr0                        11:0    1   2.7G  0 rom  
nvme0n1                   259:0    0    80G  0 disk 
├─nvme0n1p1               259:1    0     1G  0 part /boot/efi
├─nvme0n1p2               259:2    0     2G  0 part /boot
└─nvme0n1p3               259:3    0  76.9G  0 part 
  └─ubuntu--vg-ubuntu--lv 252:0    0  38.5G  0 lvm  /
nvme0n2                   259:4    0    20G  0 disk

Bootstrap Ceph Cluster

Let us install microceph.

You can purge any existing installation, or restart installation in case something goes wrong later.

# This will remove any existing installaion
sudo snap remove microceph --purge

The following bootstraps a new cluster:

manas@manas-s01:~$ sudo snap install microceph --channel=stable
microceph (squid/stable) 19.2.0+snap3b53da1c21 from Canonical✓ installed
manas@manas-s01:~$ sudo microceph cluster bootstrap
manas@manas-s01:~$ sudo microceph status
MicroCeph deployment summary:
- manas-s01 (192.168.148.134)
  Services: mds, mgr, mon
  Disks: 0

We now have a single-node cluster. Adding other nodes is a bit different from microk8s. The cluster add command generates a unique token that includes the hostname. If the cluster join fails, ensure you have used the correct hostname. For example, the VMs in this demo have hostname manas-s01, manas-s02 and mans-s03. Naming things is hard.

# Generate token to add nodes
$ sudo microceph cluster add <hostname>
<token>
# For each node 
$ sudo microceph cluster join <token>
# Master Node
manas@manas-s01:~$ sudo microceph status
MicroCeph deployment summary:
- manas-s01 (192.168.148.135)
  Services: mds, mgr, mon
  Disks: 0
- manas-s02 (192.168.148.136)
  Services: mds, mgr, mon
  Disks: 0
- manas-s03 (192.168.148.137)
  Services: mds, mgr, mon
  Disks: 0

Next, we will claim storage to be consumed by the cluster. Remember, we kept an extra disk for this purpose. Repeat the following for each node:

# Repeat for each node 
manas@manas-s01:~$ sudo microceph disk add /dev/nvme0n2 --wipe

+--------------+---------+
|     PATH     | STATUS  |
+--------------+---------+
| /dev/nvme0n2 | Success |
+--------------+---------+

# Status shows that we have 3 OSDs
manas@manas-s01:~$ sudo microceph status 
MicroCeph deployment summary:
- manas-s01 (192.168.148.134)
  Services: mds, mgr, mon, osd
  Disks: 1
- manas-s02 (192.168.148.136)
  Services: mds, mgr, mon, osd
  Disks: 1
- manas-s03 (192.168.148.135)
  Services: mds, mgr, mon, osd
  Disks: 1

Check the cluster and disk status:

manas@manas-s01:~$ sudo microceph.ceph status 
  cluster:
    id:     e43d58a8-deb0-43d9-b7ef-d6159f114c02
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum manas-s01,manas-s02,manas-s03 (age 5m)
    mgr: manas-s01(active, since 52m), standbys: manas-s02, manas-s03
    osd: 3 osds: 3 up (since 101s), 3 in (since 108s)

  data:
    pools:   1 pools, 1 pgs
    objects: 2 objects, 577 KiB
    usage:   81 MiB used, 60 GiB / 60 GiB avail
    pgs:     1 active+clean

manas@manas-s01:~$ sudo microceph disk list
Disks configured in MicroCeph:
+-----+-----------+-----------------------------------------------------------+
| OSD | LOCATION  |                           PATH                            |
+-----+-----------+-----------------------------------------------------------+
| 1   | manas-s01 | /dev/disk/by-id/nvme-eui.3e9ca0d1c76f942a000c296b819ff947 |
+-----+-----------+-----------------------------------------------------------+
| 2   | manas-s02 | /dev/disk/by-id/nvme-eui.3e9ca0d1c76f942a000c296b819ff947 |
+-----+-----------+-----------------------------------------------------------+
| 3   | manas-s03 | /dev/disk/by-id/nvme-eui.3e9ca0d1c76f942a000c296b819ff947 |
+-----+-----------+-----------------------------------------------------------+

Now, to consume File and Object storage, we need to enable the relevant services.

For example, we enable rgw for object storage on all the nodes

$ sudo microceph enable rgw
$ sudo microceph status 
MicroCeph deployment summary:
- manas-s01 (192.168.148.134)
  Services: mds, mgr, mon, rgw, osd
  Disks: 1
- manas-s02 (192.168.148.136)
  Services: mds, mgr, mon, rgw, osd
  Disks: 1
- manas-s03 (192.168.148.135)
  Services: mds, mgr, mon, rgw, osd
  Disks: 1

Congratulations, your multi node Ceph cluster is ready!

Note that microceph commands are different from the ceph CLI

Reference docs for the Squid Release of Ceph:

• https://canonical-microceph.readthedocs-hosted.com/en/v19.2.0-squid/reference/

• https://docs.ceph.com/en/squid/man/8/ceph/

There are many ways to deploy Kubernetes (k8s) clusters locally. It's similar to starting with Linux; first, you choose a distribution, then explore the different versions, packages, and customizations.

You can begin with a desktop app like Docker or Podman, which integrate well with k8s. Most IDEs have built-in support or plugins for working with k8s.

Once you move beyond the basics, you may face some limitations and inconveniences. If you're running the cluster on a laptop, you'll need reliable pause and resume features. It can be frustrating if you resume the cluster and the services are not healthy. You can always reset or reinstall, so choose your distributions carefully.

For this series, I'm sticking with Canonical solutions because Microk8s and MicroCeph have worked well. Integrating these with other tools wasn't straightforward. I'm a learner, not an expert in this area.

Preprare Infrastructure

The goal is to use cloud-native storage. This requires raw disks that will be used by Ceph. So, instead of using containers, we use VMs as nodes to create the cluster. To enable high availability, we will deploy a multi node cluster. We will start with preparing VMs to create the multi node k8s cluster.

Create Ubuntu VMs

To deploy our cluster, we need to create multiple virtual machines. For these example, we will use Ubuntu VMs running on VMware Fusion:

Prerequisites

• A desktop hypervisor like VMware Fusion or Workstation. Steps below are using Fusion on a Macbook.

• Ubuntu Server LTS ISO. The example uses MacBook M1, so images are arm based.

• At least 50GB free disk space per VM. The disk are thin provisioned but sufficient disk space is recommended.

• Basic experience with OS installation. We are using Ubuntu server version, which does not have a desktop environment.

Creating Virtual Machines

• Launch VMware Fusion and click "+" to create a new virtual machine

• Drag and drop the Ubuntu Server ISO or click "Create a custom virtual machine"

• Select "Linux" and "Ubuntu 64-bit" as the operating system

• Configure VM Resources for each node:

  • CPUs: 4 cores minimum

  • Memory: 8GB minimum

  • Storage:

    • Primary disk 50GB minimum

    • Additional 20 GB disk to be consumed by Ceph (covered in another post)

  • Network: Bridge or NAT networking

• Complete the Ubuntu installation process:

  • Choose "Install Ubuntu Server"

  • Select language and keyboard layout

  • Configure network settings (preferably static IP)

  • Set up username and password

  • Install OpenSSH server when prompted

Post-Installation Setup

If you plan to enable Ceph on the cluster, ensure you have additional disks:

manas@manas-s01:~$ lsblk | grep -v loop
NAME                      MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sr0                        11:0    1   2.7G  0 rom  
nvme0n1                   259:0    0    80G  0 disk 
├─nvme0n1p1               259:1    0     1G  0 part /boot/efi
├─nvme0n1p2               259:2    0     2G  0 part /boot
└─nvme0n1p3               259:3    0  76.9G  0 part 
  └─ubuntu--vg-ubuntu--lv 252:0    0  38.5G  0 lvm  /
nvme0n2                   259:4    0    20G  0 disk

As we are using Ubuntu Server, only remote console or SSH is available.

# Update the system
sudo apt update && sudo apt upgrade -y

# Optional package to support copy/paste etc.
sudo apt install -y open-vm-tools

Optional: Assign a static IP to the VM. You can use a netplan config like below:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens160:
      dhcp4: no
      addresses:
        - <ip>/24
      routes:
        - to: default
          via: <gateway>
      nameservers:
          addresses: [1.1.1.1,8.8.8.8]

Refer to Ubuntu network configuration docs for details

Clone VMs

We need to create at least three VMs for the cluster. There are ways to automate this step with packer, ansible, etc. However, we can create Linked Clone which is a cool feature:

A linked clone is a VMware virtual machine that shares the virtual disk of the source virtual machine.

1. First shutdown the master VM,

2. Then from the VM Library, right click and create a Linked Clone

3. Set a unique hostname and IP and reboot

4. Repeat the steps 2 and 3 for the third VM

Once the VMs are up, make sure to give each VM a unique hostname and IP address:

hostnamectl set <hostname>
# Reboot if required. Ensure each VM has unique name and IP.
# Change the netplan config: 
# https://documentation.ubuntu.com/server/explanation/networking/configuring-networks
sudo netplan apply
# Reboot
sudo reboot

Now, to be able to run commands, it is better to setup password less SSH

$ ssh-copy-id <username>@<hostame> 
# Enter the passphrase and password when prompted
# Repeat for all the 3 VMs

Initialize the k8s cluster

Start mircok8s on the master node and then run add-node from the other nodes:

In some cases, k8s may fail to start with a missing file error: microk8s/issues/4361

As a workaround, create the missing file and restart k8s:

# Install
sudo snap install microk8s --classic --channel=1.32
# Setup User permissions
sudo usermod -a -G microk8s $USER && \
mkdir -p ~/.kube && \
chmod 0700 ~/.kube
# Check status (start if required)
microk8s status
# In case of failure to start, use inspect
microk8s inspect
# Workaround to missing file error
sudo touch /var/snap/microk8s/8147/var/kubernetes/backend/localnode.yaml

Check the node status from kubectl

manas@manas-s01:~$ microk8s status
microk8s is running
high-availability: no
  datastore master nodes: 127.0.0.1:19001
  datastore standby nodes: none
addons:
  enabled:
    dns                  # (core) CoreDNS
    ha-cluster           # (core) Configure high availability on the current node
    helm                 # (core) Helm - the package manager for Kubernetes
    helm3                # (core) Helm 3 - the package manager for Kubernetes
  disabled:
    cert-manager         # (core) Cloud native certificate management
    cis-hardening        # (core) Apply CIS K8s hardening
    community            # (core) The community addons repository
    dashboard            # (core) The Kubernetes dashboard
    host-access          # (core) Allow Pods connecting to Host services smoothly
    hostpath-storage     # (core) Storage class; allocates storage from host directory
    ingress              # (core) Ingress controller for external access
    kube-ovn             # (core) An advanced network fabric for Kubernetes
    mayastor             # (core) OpenEBS MayaStor
    metallb              # (core) Loadbalancer for your Kubernetes cluster
    metrics-server       # (core) K8s Metrics Server for API access to service metrics
    minio                # (core) MinIO object storage
    observability        # (core) A lightweight observability stack for logs, traces and metrics
    prometheus           # (core) Prometheus operator for monitoring and logging
    rbac                 # (core) Role-Based Access Control for authorisation
    registry             # (core) Private image registry exposed on localhost:32000
    rook-ceph            # (core) Distributed Ceph storage using Rook
    storage              # (core) Alias to hostpath-storage add-on, deprecated

manas@manas-s01:~$ microk8s kubectl get no
NAME        STATUS   ROLES    AGE   VERSION
manas-s01   Ready    <none>   22m   v1.32.3

Add other nodes to the cluster

manas@manas-s01:~$ microk8s add-node
From the node you wish to join to this cluster, run the following:
microk8s join 192.168.148.134:25000/...

Use the '--worker' flag to join a node as a worker not running the control plane, eg:
microk8s join 192.168.148.134:25000/... --worker

If the node you are adding is not reachable through the default interface you can use one of the following:
microk8s join 192.168.148.134:25000/.../...
microk8s join 172.17.0.1:25000/.../...

From the nodes, join the cluster by pasting the command from above.

manas@manas-s02:~$ microk8s join 192.168.148.134:25000/.../...
Contacting cluster at 192.168.148.134
Waiting for this node to finish joining the cluster. .. .. .. .. .. .. .. .. .. ..  
Successfully joined the cluster.

From the Master Node, ensure k8s is up and running. We should have HA enabled with 3 nodes.

manas@manas-s01:~$ microk8s status
microk8s is running
high-availability: yes
  datastore master nodes: 192.168.148.134:19001 192.168.148.136:19001 192.168.148.135:19001
  datastore standby nodes: none
addons:
  enabled:
    dns                  # (core) CoreDNS
    ha-cluster           # (core) Configure high availability on the current node
    helm                 # (core) Helm - the package manager for Kubernetes
    helm3                # (core) Helm 3 - the package manager for Kubernetes
  disabled:
    cert-manager         # (core) Cloud native certificate management
    cis-hardening        # (core) Apply CIS K8s hardening
    community            # (core) The community addons repository
    dashboard            # (core) The Kubernetes dashboard
    host-access          # (core) Allow Pods connecting to Host services smoothly
    hostpath-storage     # (core) Storage class; allocates storage from host directory
    ingress              # (core) Ingress controller for external access
    kube-ovn             # (core) An advanced network fabric for Kubernetes
    mayastor             # (core) OpenEBS MayaStor
    metallb              # (core) Loadbalancer for your Kubernetes cluster
    metrics-server       # (core) K8s Metrics Server for API access to service metrics
    minio                # (core) MinIO object storage
    observability        # (core) A lightweight observability stack for logs, traces and metrics
    prometheus           # (core) Prometheus operator for monitoring and logging
    rbac                 # (core) Role-Based Access Control for authorisation
    registry             # (core) Private image registry exposed on localhost:32000
    rook-ceph            # (core) Distributed Ceph storage using Rook
    storage              # (core) Alias to hostpath-storage add-on, deprecated

Once all nodes have joined, we can see the following output:

manas@manas-s01:~$ sudo microk8s kubectl get no
NAME        STATUS   ROLES    AGE     VERSION
manas-s01   Ready    <none>   48m     v1.32.3
manas-s02   Ready    <none>   4m39s   v1.32.3
manas-s03   Ready    <none>   4m26s   v1.32.3

You can see all the resources that are running

manas@manas-s01:~$ microk8s kubectl get all --all-namespaces
NAMESPACE     NAME                                           READY   STATUS    RESTARTS   AGE
kube-system   pod/calico-kube-controllers-5947598c79-z6wcb   1/1     Running   0          51m
kube-system   pod/calico-node-f2jv7                          1/1     Running   0          29m
kube-system   pod/calico-node-jdmvj                          1/1     Running   0          7m56s
kube-system   pod/calico-node-lfbqs                          1/1     Running   0          7m43s
kube-system   pod/coredns-79b94494c7-k98hm                   1/1     Running   0          51m

NAMESPACE     NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                  AGE
default       service/kubernetes   ClusterIP   10.152.183.1    <none>        443/TCP                  51m
kube-system   service/kube-dns     ClusterIP   10.152.183.10   <none>        53/UDP,53/TCP,9153/TCP   51m

NAMESPACE     NAME                         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
kube-system   daemonset.apps/calico-node   3         3         3       3            3           kubernetes.io/os=linux   51m

NAMESPACE     NAME                                      READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/calico-kube-controllers   1/1     1            1           51m
kube-system   deployment.apps/coredns                   1/1     1            1           51m

NAMESPACE     NAME                                                 DESIRED   CURRENT   READY   AGE
kube-system   replicaset.apps/calico-kube-controllers-5947598c79   1         1         1       51m
kube-system   replicaset.apps/coredns-79b94494c7                   1         1         1       51m

Congratulations you have a multi node k8s running!

Please note that microk8s commands are different from other k8s CLIs. As this is a compliant k8s cluster, other tools should also work. The installation is snap based, so config and log files are under the snap directory. Refer to https://microk8s.io/docs/command-reference

Distributed storage systems spread data across multiple nodes or machines, offering benefits like high availability, fault tolerance, and scalability. These systems ensure data remains accessible even if some nodes fail. The implementation of these features varies across products.

Key Components

• Data Distribution: Information is split and stored across multiple nodes

• Replication: Data is copied to multiple locations for redundancy

• Consistency: Mechanisms to ensure data remains synchronized across nodes

• Load Balancing: Even distribution of storage and access load across nodes

Kubernetes Storage Architecture

Kubernetes provides a robust framework for container orchestration, including storage management through:

• Persistent Volumes (PV): Storage resources in the cluster

• Persistent Volume Claims (PVC): Storage requests by applications

• Storage Classes: Different types of storage with varying performance characteristics

Ceph: A Distributed Storage Solution

Ceph is a highly scalable distributed storage system that provides:

• Object Storage: Through RADOS Gateway (RGW)

• Block Storage: Through RADOS Block Device (RBD)

• File Storage: Through CephFS

Ceph achieves high reliability through data replication and self-healing capabilities.

Rook: Bridging Kubernetes and Ceph

Rook acts as a storage orchestrator that integrates Ceph with Kubernetes:

• Automated Management: Handles deployment, configuration, and scaling of Ceph clusters

• Native Integration: Provides storage services directly to Kubernetes applications

• Operator Pattern: Uses Kubernetes operators for automated management and maintenance

• Storage Classes: Creates and manages Kubernetes storage classes for Ceph storage

Benefits of the Combined Stack

Using Kubernetes with Ceph through Rook provides:

• Cloud-Native Storage: Fully containerized storage solution

• Dynamic Provisioning: Automatic storage allocation based on application needs

• High Availability: Resilient storage infrastructure with automated failover

• Scalability: Easy scaling of both compute and storage resources

In this series, we will deploy a distributed storage cluster locally. We'll start by creating VMs for multi-node clusters, then set up multi-node Kubernetes and Ceph clusters. Finally, we'll integrate Kubernetes and Ceph using Rook. Here’s a birds’ eye view:

---
config:
  theme: neutral
  layout: dagre
  look: neo
---
flowchart TB
 subgraph subGraph0["Kubernetes Cluster"]
        CP["Control Plane"]
        WN["Worker Nodes"]
        APP["Applications"]
  end
 subgraph subGraph1["Rook Storage Operator"]
        ROOK["Rook Operator"]
  end
 subgraph subGraph2["Storage Services"]
        RBD["Block Storage<br>RBD"]
        CEPHFS["File System<br>CephFS"]
        RGW["Object Storage<br>S3/Swift"]
  end
 subgraph subGraph3["Ceph Storage Cluster"]
        CEPH["Ceph Cluster"]
        subGraph2
  end
 subgraph subGraph4["Physical Infrastructure"]
        DISKS["Physical Disks"]
  end
    CP --> WN
    WN --> APP & ROOK
    ROOK --> CEPH
    CEPH --> RBD & CEPHFS & RGW & DISKS
    RBD --> APP
    CEPHFS --> APP
    RGW --> APP
     CP:::k8s
     WN:::k8s
     APP:::k8s
     ROOK:::rook
     RBD:::ceph
     CEPHFS:::ceph
     RGW:::ceph
     CEPH:::ceph
     DISKS:::infra
    classDef k8s fill:#e1f5fe
    classDef rook fill:#fce4ec
    classDef ceph fill:#fff3e0
    classDef storage fill:#e8f5e8
    classDef infra fill:#f5f5f5

Large Language Models (LLMs) are incredibly powerful, but their knowledge is often limited to the data they were trained on. What if you could give them access to real-time information or allow them to interact with other systems? That's where "tools" come in. The Cerebras SDK makes it straightforward to equip your LLM applications with the ability to use custom functions, effectively extending their capabilities.

This improves upon the official guide by using a working demo API and fixing some code bugs. Thanks to the generous free API by Cerebras which lets you try out the (current) latest Qwen 3 model.

In this post, we'll walk through a practical example: building a financial assistant that can calculate the Simple Moving Average (SMA) for stock data. We'll use the Cerebras SDK to enable an LLM to call our custom Python function for this calculation.

A Stock-Savvy Assistant Version 1

Our objective is to create a system where a user can ask a question like, "What's the 10-day moving average for company A over the last 50 days?" and the LLM, instead of just guessing, can use a specific tool (our Python function) to get the precise answer.

Step 1: Gathering the Data

First, we need a way to get stock data. Our demo uses the Alpha Vantage API. While the original guide uses mock data, here we implement get_stocks_data function to fetch daily time series data for a given stock symbol using Alpha Vantage APIs. We need to convert the dict to a list with date as a key in each item.

import requests

# URLs for fetching stock data from Alpha Vantage API
urls = [
    f"https://www.alphavantage.co/query?function=TIME_SERIES_DAILY&symbol=APPL&outputsize=full&apikey={api_key}",
    f"https://www.alphavantage.co/query?function=TIME_SERIES_DAILY&symbol=GOOG&outputsize=full&apikey={api_key}",
]

def get_stocks_data(url: str) -> list[dict]:
    """
    Fetches and processes daily time series stock data from a given Alpha Vantage URL.
    """
    r = requests.get(url)
    r.raise_for_status() # Good practice to check for request errors
    data = r.json()
    # Extract the 'Time Series (Daily)' data from the response
    # Add error handling for unexpected API response structure
    time_series_data = data.get("Time Series (Daily)")
    if not time_series_data:
        raise ValueError("Could not find 'Time Series (Daily)' in API response.")

    stocks_data = []
    # Reformat the data into a list of dictionaries
    for s_date, s_data in time_series_data.items():
        n = {"date": s_date}
        n.update(s_data)
        stocks_data.append(n)
    return stocks_data

# Fetch stock data for two predefined companies
company_a_data = get_stocks_data(urls[0])
company_b_data = get_stocks_data(urls[1])

# Store the fetched company data in a dictionary for easy access
available_data = {
    "company_a": company_a_data,
    "company_b": company_b_data,
}

This function fetches data for "IBM" and "RELIANCE.BSE" and stores it in available_data.

Step 2: The Core Logic - Calculating Moving Average

Next, we define the function that will act as our "tool". The calculate_moving_average function takes a data reference (e.g., "company_a"), the number of days to consider, and the window size for the moving average

def calculate_moving_average(
        data_reference: str, num_days: int, window_size: int
) -> list[dict[str, float]]:
    """
    Calculates the moving average for a specified stock.
    """
    if data_reference not in available_data:
        raise ValueError(
            f"Invalid data reference. Available options: {list(available_data.keys())}"
        )

    stock_data = available_data[data_reference]

    if num_days < window_size:
        raise ValueError("num_days must be greater than or equal to window_size")

    if len(stock_data) < num_days:
        raise ValueError("Insufficient data for the specified number of days")

    # Data is typically sorted newest to oldest from Alpha Vantage.
    # For SMA, we usually want to process oldest to newest or ensure correct slicing.
    # Assuming data is sorted: stock_data[0] is newest, stock_data[-1] is oldest.
    # To get the most recent 'num_days', we might need to reverse or slice carefully.
    # For this example, let's assume the API returns data oldest to newest,
    # or that get_stocks_data sorts it that way. If not, this needs adjustment.
    # If data is newest to oldest:
    # recent_data_points = stock_data[:num_days] # Get the N most recent
    # recent_data_points.reverse() # Process oldest to newest for SMA calculation

    # Let's stick to the original logic of taking the last 'num_days' from the list
    # This implies the list is already sorted oldest to newest.
    recent_data_points: list[dict] = stock_data[num_days:]
    moving_averages: list[dict[str, float]] = []

    if not recent_data_points or len(recent_data_points) < window_size:
        return [] # Not enough data to calculate even one SMA

    # Initialize the price window with the closing prices of the first 'window_size' days
    price_window: list[float] = [
        float(item["4. close"]) for item in recent_data_points[:window_size]
    ]
    # Add the first SMA if we have exactly window_size data points
    if len(price_window) == window_size:
         moving_averages.append({
             "date": recent_data_points[window_size -1]["date"], # Date of the last day in the window
             "movingAverage": round(sum(price_window) / window_size, 2)
         })

    # Calculate moving average for the remaining days
    for i in range(window_size, len(recent_data_points)):
        current_data = recent_data_points[i]
        current_price = float(current_data["4. close"])

        price_window.pop(0) # Remove the oldest price
        price_window.append(current_price) # Add the newest price
        average = round(sum(price_window) / window_size, 2)

        moving_averages.append({"date": current_data["date"], "movingAverage": average})

    return moving_averages

This function performs the actual SMA calculation. Note the input validation and the logic for sliding the window.

Step 3: Describing the Tool to the LLM

For the LLM to understand how to use our function, we need to provide a schema for its parameters. We'll use Pydantic which is excellent for this:

from pydantic import BaseModel, Field
from typing import Literal

class CalculateMovingAverageArgs(BaseModel):
    """
    Pydantic model defining the arguments for the calculate_moving_average function.
    Used for schema validation and generation for AI tool usage.
    """
    data_reference: Literal["company_a", "company_b"] = Field(
        ...,
        description="The key to access specific stock data in the stock_data dictionary.",
    )
    num_days: int = Field(
        ..., description="The number of recent days to consider for calculation."
    )
    window_size: int = Field(..., description="The size of the moving average window.")

This CalculateMovingAverageArgs model clearly defines the expected inputs, their types, and descriptions.

Step 4: Registering the Tool with Cerebras SDK

Now, we tell the Cerebras SDK about our tool:

# Define the tool (function) that the AI model can use
tools = [
    {
        "type": "function",
        "function": {
            "name": "calculate_moving_average",
            "description": "Calculate the moving average of stock data for a specified number of recent days.",
            "parameters": CalculateMovingAverageArgs.model_json_schema(),
        },
    }
]

We create a list of tool definitions. Each tool has a type ("function"), a name (matching our Python function name), a description (for the LLM to understand its purpose), and parameters (using the JSON schema from our Pydantic model).

Step 5: Making the API Call

With everything set up, we can now interact with the LLM:

import os
from cerebras.cloud.sdk import Cerebras

# Define the messages for the AI model, including system prompt and user query
messages = [
    {
        "role": "system",
        "content": "You are a helpful financial analyst. Use the supplied tools to assist the user.",
    },
    {
        "role": "user",
        "content": "What's the 10-day moving average for company A over the last 50 days?",
    },
]

# Initialize the Cerebras SDK client using API key from environment variable
client = Cerebras(
    api_key=os.environ.get("CEREBRAS_API_KEY"),
)

# Make a chat completion request to the Cerebras API
response = client.chat.completions.create(
    model="qwen-3-32b",  # Specify the AI model to use
    messages=messages,
    tools=tools,  # Provide the available tools to the model
)

We initialize the Cerebras client, define our conversation messages, and importantly, pass our tools definition to the create method.

Step 6: Handling the LLM's Response

The LLM might respond directly, or it might decide to use our tool. We need to handle both cases

# Process the AI model's response
content = response.choices[0].message.content
if content:
    print("AI Response Content:")
    print(content)

# Check if the AI decided to call a function
if response.choices[0].message.tool_calls:
    tool_call = response.choices[0].message.tool_calls[0] # Get the first tool call
    function_call = tool_call.function
    if function_call.name == "calculate_moving_average":
        # Parse the arguments provided by the AI for the function call
        try:
            arguments = json.loads(function_call.arguments)
            # Call the local function with the AI-provided arguments
            result = calculate_moving_average(**arguments)
            print("\\nResult of function call (calculate_moving_average):")
            print(result)

        except json.JSONDecodeError:
            print(f"Error: Could not decode arguments: {function_call.arguments}")
        except Exception as e:
            print(f"Error executing function {function_call.name}: {e}")

If response.choices[0].message.tool_calls is present, it means the LLM wants to use one of our tools. We extract the function name and arguments, then execute our local calculate_moving_average function.

The commented-out section shows how you could then send this result back to the LLM. This allows the LLM to formulate a natural language response based on the data retrieved by the tool, making the interaction more conversational.

Here's a sample output:

[{'date': '2025-06-04', 'movingAverage': 200.0}, {'date': '2025-06-03', 'movingAverage': 200.76}, {'date': '2025-06-02', 'movingAverage': 201.09}, {'date': '2025-05-30', 'movingAverage': 201.53}, {'date': '2025-05-29', 'movingAverage': 201.6}, {'date': '2025-05-28', 'movingAverage': 201.77}, {'date': '2025-05-27', 'movingAverage': 201.52}, {'date': '2025-05-23', 'movingAverage': 200.9}, {'date': '2025-05-22', 'movingAverage': 200.65}, {'date': '2025-05-21', 'movingAverage': 200.79}, {'date': '2025-05-20', 'movingAverage': 201.2}, {'date': '2025-05-19', 'movingAverage': 201.75}, {'date': '2025-05-16', 'movingAverage': 202.7}, {'date': '2025-05-15', 'movingAverage': 203.77}, {'date': '2025-05-14', 'movingAverage': 205.0}, {'date': '2025-05-13', 'movingAverage': 206.25}, {'date': '2025-05-12', 'movingAverage': 207.31}, {'date': '2025-05-09', 'movingAverage': 207.64}, {'date': '2025-05-08', 'movingAverage': 207.25}, {'date': '2025-05-07', 'movingAverage': 206.67}, {'date': '2025-05-06', 'movingAverage': 205.83}, {'date': '2025-05-05', 'movingAverage': 204.84}, {'date': '2025-05-02', 'movingAverage': 204.25}, {'date': '2025-05-01', 'movingAverage': 204.44}, {'date': '2025-04-30', 'movingAverage': 204.46}, {'date': '2025-04-29', 'movingAverage': 204.28}, {'date': '2025-04-28', 'movingAverage': 204.22}, {'date': '2025-04-25', 'movingAverage': 205.29}, {'date': '2025-04-24', 'movingAverage': 206.38}, {'date': '2025-04-23', 'movingAverage': 207.22}, {'date': '2025-04-22', 'movingAverage': 207.34}, {'date': '2025-04-21', 'movingAverage': 206.77}, {'date': '2025-04-17', 'movingAverage': 205.93}, {'date': '2025-04-16', 'movingAverage': 204.03}, {'date': '2025-04-15', 'movingAverage': 202.99}, {'date': '2025-04-14', 'movingAverage': 202.12}, {'date': '2025-04-11', 'movingAverage': 200.92}, {'date': '2025-04-10', 'movingAverage': 199.03}, {'date': '2025-04-09', 'movingAverage': 198.08}, {'date': '2025-04-08', 'movingAverage': 194.87}]

Process finished with exit code 0

What happens if there is no suitable tool is available? Let us modify the message and try again to see the result:

messages = [
    {
        "role": "system",
        "content": "You are a helpful financial analyst. Use the supplied tools to assist the user.",
    },
    {
        "role": "user",
        "content": "Give an overview of the company A",
    },
]

# Make a chat completion request to the Cerebras API
response = client.chat.completions.create(
    model="qwen-3-32b",  
    messages=messages,
    tools=tools, 
)
# Process the AI model's response
content = response.choices[0].message.content
if content:
    print("AI Response Content:")
    print(content)

This will print the message following:

I don't have access to a function/tool that provides general company overviews. The available tool only supports calculating moving averages for stock data. Would you like me to help with a moving average calculation for Company A's stock instead?

This is where multi tool use comes into picture. However, we are not implementing multi tool in this demo.

Stock-Savvy Assistant Version 2

If you noticed, we did not use the data from company B at all.

Let us fix that by comparing the SMA for both companies. However, there’s a challenge:

• calculate_moving_average and CalculateMovingAverageArgs accept data_reference not available_data

We can either fix the signatures or use Python partial

No points for guessing, that we will use partial instead of repeating the same arg every where.

Here’s the updated version, with the following changes:

1. Use dotenv to read API Keys

2. Calculate SMA of both company A and B

3. Implement partials to use the same tool function and args with available_data

import json
import os
from collections import deque
from functools import partial
from typing import Literal, List, Dict

import requests
from cerebras.cloud.sdk import Cerebras
from dotenv import load_dotenv
from pydantic import BaseModel, Field

load_dotenv()

v_api_key = os.environ.get("STOCK_API_KEY")
if not v_api_key:
    print("Error: STOCK_API_KEY environment variable not set.")

STOCK_URLS = {
    "company_a": f"https://www.alphavantage.co/query?function=TIME_SERIES_DAILY&symbol=AAPL&outputsize=full&apikey={v_api_key}",
    "company_b": f"https://www.alphavantage.co/query?function=TIME_SERIES_DAILY&symbol=GOOG&outputsize=full&apikey={v_api_key}",
}

def get_stocks_data(url: str) -> List[Dict]:
    """
    Fetches and processes daily time series stock data from a given Alpha Vantage URL.
    ... (docstring remains the same) ...
    """
    response = requests.get(url)
    response.raise_for_status()
    data = response.json()

    time_series_data = data.get("Time Series (Daily)")
    if not time_series_data:
        # Add the API response note to the error for better debugging
        note = data.get("Note")
        if note:
            raise ValueError(f"API response missing 'Time Series (Daily)' data. Note: {note}")
        raise ValueError("API response missing 'Time Series (Daily)' data.")

    stocks_data = []
    for date_str, daily_data in time_series_data.items():
        record = {"date": date_str}
        record.update(daily_data)
        stocks_data.append(record)

    stocks_data.reverse()
    return stocks_data


def calculate_moving_average(
    available_data: Dict,  # <-- Dependency is now an explicit argument
    data_reference: str,
    num_days: int,
    window_size: int,
) -> List[Dict[str, float]]:
    """
    Calculates the moving average for a specified stock over a given number of days
    and window size.

    Args:
        available_data: A dictionary containing the pre-loaded stock data.
        ... (other args remain the same) ...
    """
    if data_reference not in available_data:
        raise ValueError(
            f"Invalid data reference. Available options: {list(available_data.keys())}"
        )

    stock_data = available_data[data_reference]

    if num_days < window_size:
        raise ValueError("num_days must be greater than or equal to window_size")

    if len(stock_data) < num_days:
        raise ValueError(
            f"Insufficient data for the specified number of days. "
            f"Requested: {num_days}, Available: {len(stock_data)}"
        )

    recent_data = stock_data[-num_days:]
    moving_averages = []
    price_window = deque(maxlen=window_size)

    for i in range(len(recent_data)):
        current_data = recent_data[i]
        price_window.append(float(current_data["4. close"]))

        if len(price_window) == window_size:
            average = round(sum(price_window) / window_size, 2)
            moving_averages.append(
                {"date": current_data["date"], "movingAverage": average}
            )

    return moving_averages


def compare_moving_averages(
    available_data: Dict, num_days: int, window_size: int
) -> Dict:
    """
    Calculates and compares the latest moving average of two companies.

    Args:
        available_data: A dictionary containing the pre-loaded stock data.
        ... (other args remain the same) ...
    """
    try:
        # Pass the dependency down to the next function
        ma_a_list = calculate_moving_average(
            available_data, "company_a", num_days, window_size
        )
        ma_b_list = calculate_moving_average(
            available_data, "company_b", num_days, window_size
        )

        latest_ma_a = ma_a_list[-1] if ma_a_list else None
        latest_ma_b = ma_b_list[-1] if ma_b_list else None

        if not latest_ma_a or not latest_ma_b:
            return {
                "error": "Could not calculate moving average for one or both companies."
            }

        result = {
            "company_a": {
                "latest_date": latest_ma_a["date"],
                "moving_average": latest_ma_a["movingAverage"],
            },
            "company_b": {
                "latest_date": latest_ma_b["date"],
                "moving_average": latest_ma_b["movingAverage"],
            },
            "summary": (
                f"As of their latest data points, Company A's {window_size}-day moving average is "
                f"{latest_ma_a['movingAverage']} ({latest_ma_a['date']}), while Company B's is "
                f"{latest_ma_b['movingAverage']} ({latest_ma_b['date']})."
            ),
        }
        return result
    except ValueError as e:
        return {"error": str(e)}


class CalculateMovingAverageArgs(BaseModel):
    """Defines arguments for the calculate_moving_average function."""
    data_reference: Literal["company_a", "company_b"] = Field(..., description="The key for the stock data.")
    num_days: int = Field(..., description="The number of recent days for calculation.")
    window_size: int = Field(..., description="The size of the moving average window.")


class CompareMovingAveragesArgs(BaseModel):
    """Defines arguments for the compare_moving_averages function."""
    num_days: int = Field(..., description="The number of recent days for calculation.")
    window_size: int = Field(..., description="The size of the moving average window.")


def main():
    """
    Main function to run the financial analyst assistant.
    """
    print("Fetching stock data...")
    loaded_data = {key: get_stocks_data(url) for key, url in STOCK_URLS.items()}
    print("Data loaded successfully.")

    calculate_moving_average_tool = partial(
        calculate_moving_average, available_data=loaded_data
    )
    compare_moving_averages_tool = partial(
        compare_moving_averages, available_data=loaded_data
    )

    tools = [
        {
            "type": "function",
            "function": {
                "name": "calculate_moving_average",
                "description": "Calculate the moving average of a single company's stock data.",
                "parameters": CalculateMovingAverageArgs.model_json_schema(),
            },
        },
        {
            "type": "function",
            "function": {
                "name": "compare_moving_averages",
                "description": "Compare the moving averages of company A and company B.",
                "parameters": CompareMovingAveragesArgs.model_json_schema(),
            },
        },
    ]

    available_functions = {
        "calculate_moving_average": calculate_moving_average_tool,
        "compare_moving_averages": compare_moving_averages_tool,
    }

    messages = [
        {
            "role": "system",
            "content": "You are a helpful financial analyst. Use the supplied tools to assist the user. "
                       "When comparing, state which company has the higher moving average and by how much.",
        },
        {
            "role": "user",
            "content": "How do the 10-day moving averages for company A and company B compare over the last 50 days?",
        },
    ]

    ai_api_key = os.environ.get("CEREBRAS_API_KEY")
    if not ai_api_key:
        print("Error: CEREBRAS_API_KEY environment variable not set.")
        return

    client = Cerebras(api_key=ai_api_key)

    print("\n--- Sending request to LLM ---")
    response = client.chat.completions.create(
        model="qwen-3-32b",
        messages=messages,
        tools=tools,
        tool_choice="auto",
    )

    response_message = response.choices[0].message

    if response_message.tool_calls:
        print("LLM decided to use a tool.")
        tool_call = response_message.tool_calls[0]
        function_name = tool_call.function.name

        if function_name not in available_functions:
            print(f"Error: LLM tried to call an unknown function: {function_name}")
            return

        print(f"Calling function: {function_name}")
        function_to_call = available_functions[function_name]

        try:
            arguments = json.loads(tool_call.function.arguments)
            tool_result = function_to_call(**arguments)

            print("\n--- Tool Result ---")
            print(json.dumps(tool_result, indent=2))

            print("\n--- Sending tool result back to LLM for final answer ---")
            messages.append(response_message)
            messages.append(
                {
                    "tool_call_id": tool_call.id,
                    "role": "tool",
                    "name": function_name,
                    "content": json.dumps(tool_result),
                }
            )

            final_response = client.chat.completions.create(
                model="qwen-3-32b",
                messages=messages,
            )

            final_answer = final_response.choices[0].message.content
            print("\n--- Final AI Analyst Answer ---")
            print(final_answer)

        except Exception as e:
            print(f"An error occurred during tool execution: {e}")
    else:
        print("\n--- Direct LLM Response ---")
        print(response_message.content)


if __name__ == "__main__":
    main()

Here’s a sample response:

Data loaded successfully.

--- Sending request to LLM ---
LLM decided to use a tool.
Calling function: compare_moving_averages

--- Tool Result ---
{
  "company_a": {
    "latest_date": "2025-06-20",
    "moving_average": 199.41
  },
  "company_b": {
    "latest_date": "2025-06-20",
    "moving_average": 176.11
  },
  "summary": "As of their latest data points, Company A's 10-day moving average is 199.41 (2025-06-20), while Company B's is 176.11 (2025-06-20)."
}

--- Sending tool result back to LLM for final answer ---

--- Final AI Analyst Answer ---
<think>
Okay, let me start by understanding the user's question. They want to compare the 10-day moving averages of company A and company B over the last 50 days. The tool response provided data for both companies as of June 20, 2025.

First, I need to verify if the data matches the query. The user asked for a 50-day comparison, but the tool's summary only gives the moving average as of the latest date. The answer should confirm whether the data spans the last 50 days correctly. Since the latest date is 2025-06-20 and the moving average is based on the current data up to that point, it's likely that the moving average reflects the closing prices over a period that includes the last 50 days. However, the exact comparison over the 50-day window isn't detailed in the tool's response beyond the current snapshot.

The key points here are the latest moving averages. The user asked for a comparison over the last 50 days, but the tool's output only shows the most recent numbers. This might mean that the user is interested in the current state of the moving averages, perhaps to assess recent performance trends. 

Next, I should calculate the difference between the two moving averages. Company A's is 199.41 and Company B's is 176.11. Subtracting these gives 23.3 points. To make it more meaningful, I can express this difference as a percentage of the lower moving average (Company B's). The percentage difference is (23.3 / 176.11) * 100 ≈ 13.23%. That shows how much higher Company A's moving average is in relative terms. 

I should also consider if there's any missing information. The user might expect a time series comparison or a trend analysis over the 50 days, but since the tool's response only provides the latest values, I need to clarify that my answer is based on a single point in time. It's possible that the 10-day moving averages fluctuated over the past 50 days, but without historical data, I can only state the current difference. 

Therefore, the response should highlight the latest moving averages, the absolute difference, and the percentage difference. I should also mention that the data is as of June 20, 2025, and note that a more detailed 50-day trend would require additional historical data, which isn't provided here.
</think>

**Comparison of 10-day Moving Averages:**

- **Company A**: 199.41 (as of 2025-06-20)  
- **Company B**: 176.11 (as of 2025-06-20)  

**Conclusion**:  
Company A's 10-day moving average is **$23.30 higher** than Company B's, representing a **13.23% increase** relative to Company B's value. This comparison reflects the latest data point for both companies, but historical trends over the 50-day period would require a time-series analysis (not included in the provided data).

Process finished with exit code 0

Why use tools with AI?

• Access to Real-Time Data: LLMs can query live APIs for up-to-the-minute information.

• Interacting with External Systems: Control databases, send emails, or interact with any system that has an API.

• Performing Complex Calculations: Offload specialized computations to dedicated functions, like our SMA calculator.

• Improved Accuracy and Reliability: Ground LLM responses in factual data retrieved by tools, rather than relying solely on its training.

By integrating tools with the Cerebras SDK, you can build more dynamic, capable, and reliable AI applications. This example is just the tip of the iceberg – the possibilities are vast!

fio (Flexible I/O Tester) is a versatile I/O workload generator that is used to benchmark and test storage systems. Developed by Jens Axboe, fio is capable of simulating various I/O workloads, making it a valuable tool for evaluating the performance of hard drives, SSDs, and other storage solutions. fio can be configured to perform read, write, and mixed operations with different block sizes, I/O depths, and access patterns. It supports a wide range of I/O engines, including synchronous, asynchronous, and memory-mapped I/O.

Now, think of fio as a meticulously sharpened chef's knife. In the hands of a master, it can dice, slice, and julienne storage performance with unparalleled precision. It's capable of revealing the most granular details of your disks, SSDs, and network drives. But, just like a professional knife set, fio comes with a dizzying array of blades – options, in its case. This sheer versatility, while powerful, can be utterly overwhelming to the uninitiated. You're presented with a vast toolkit, and knowing which tool to use, let alone how to wield it effectively, is a challenge in itself. Prepare to navigate a sea of parameters, from block sizes and I/O engines to queue depths and latency targets, or risk simply blunting the edge of this incredibly potent instrument.

Based on the FIO documentation from FIO documentation, there are at least 152 command-line options ( as calculated by a Gemini)

Plot using the packaged script

The fio_generate_plots script is a utility that processes the log files generated by fio and creates graphical representations of the data using GNUPLOT. The script generates plots in the SVG (Scalable Vector Graphics) format, which is supported by most modern browsers and allows for resolution-independent graphs. This makes it easier to visualise and analyse the performance data collected during FIO benchmarks.

However, to create log file, certain options should be used: write_lat_log, write_bw_log, and write_iops_log. Here's a sample FIO workload configuration file:

[global]
ioengine=libaio
direct=1
bs=4k
size=1G
runtime=60
time_based
ramp_time=10s
group_reporting
numjobs=4
log_avg_msec=1000
write_bw_log=bw
write_iops_log=iops
write_lat_log=lat

[write-test]
rw=write
filename=write_test_file

[read-test]
rw=read
filename=read_test_file

To run this workload, save the above configuration to a file named fio_workload_example.ini, and then execute the following command:

fio fio_workload_example.ini

This will generate the following log files:

• bw_log

• iops_log

• lat_log

These log files can then be used by the fio_generate_plots script to create the plots.

Now, to use the fio_generate_plots script to generate plots, follow these steps:

1. Ensure gnuplot is installed: The script requires gnuplot to generate graphs. You can install it using your package manager. For example, on Debian-based systems, you can use:

    sudo apt-get install gnuplot
   

2. Run the script: Execute the script with the required parameters:

   • subtitle: The main title for the plots.

   • xres (optional): The horizontal resolution of the plots.

   • yres (optional): The vertical resolution of the plots.

Example usage:

    ./fio_generate_plots "Benchmark Results" 1920 1080

This will generate SVG plots with the specified resolution.

3. Check the output: The script will generate SVG files in the current directory with names based on the provided subtitle and the type of data (e.g., My Benchmark Results-lat.svg, My Benchmark Results-iops.svg).

Make sure the script has executable permissions. If not, you can set them using:

chmod +x fio_generate_plots

On my machine, it gives an output:

> ls
Benchmark-bw.svg   Benchmark-clat.svg Benchmark-iops.svg Benchmark-lat.svg  Benchmark-slat.svg

Generate plots using Pandas

Now, that we have the plots as SVG, the next logical step is to automate the process and create a friendly chart. Given that there are excellent Python packages for this purpose, let us move away from gnuplot to pandas.

Here are the steps:

1. We read the file into a pandas data frame. Note that we are only using the first and second columns.

2. Collect all the data frames in a list

3. Plot them using matplotlib and save as SVGs

import glob
import sys

import matplotlib.pyplot as plt
import pandas as pd


def usage():
    print("Usage: fio_generate_plots.py subtitle [xres yres]")
    sys.exit(1)


def read_log_files(filetype):
    """
    Read fio log files into a pandas dataframe.
    :param filetype: string to search for filenames
    :return: list of pandas dataframes
    """
    logs = []
    files = glob.glob(f"*_{filetype}.log") + glob.glob(f"*_{filetype}.*.log")
    print(f"Found {len(files)} {filetype} files")
    for file in files:
        df = pd.read_csv(file, header=None, names=["time", "value", "x", "y", "z"])
        df["time"] = (
            pd.to_numeric(df["time"], errors="coerce") / 1000
        )  # Convert time to seconds
        logs.append((file, df))
    return logs


def plot(title, filetype, ylabel, scale, xres=1280, yres=768):
    """
    Generate a plot for a given dataframe and store is as a SVG file.
    :param title: Title of the plot
    :param filetype: log filetype used
    :param ylabel: Y axis label
    :param scale: scaling factor
    :param xres: X axis resolution
    :param yres: Y axis resolution
    :return: None 
    """
    logs = read_log_files(filetype)
    if not logs:
        print("No log files found")
        sys.exit(1)

    plt.figure(figsize=(xres / 100, yres / 100))
    plt.title(f"{title}\n\n{ylabel}")
    plt.xlabel("Time (sec)")
    plt.ylabel(ylabel)

    for i, (filename, df) in enumerate(logs):
        depth = filename.split(".")[1]
        plt.plot(
            df["time"],
            df["value"] / scale,
            label=f"Queue depth {depth}",
            linestyle="-",
            marker="",
        )

    plt.legend(loc="best")
    plt.grid(True)
    plt.savefig(f"{title.replace(' ', '_')}_{filetype}.svg")


def main():
    if len(sys.argv) < 2:
        usage()

    title = sys.argv[1]
    xres = int(sys.argv[2]) if len(sys.argv) > 2 else 1280
    yres = int(sys.argv[3]) if len(sys.argv) > 3 else 768

    # One plot for each log type 
    plot(title, "lat", "Time (msec)", 1000000, xres, yres)
    plot(title, "iops", "IOPS", 1, xres, yres)
    plot(title, "slat", "Time (μsec)", 1000, xres, yres)
    plot(title, "clat", "Time (msec)", 1000000, xres, yres)
    plot(title, "bw", "Throughput (KB/s)", 1, xres, yres)


if __name__ == "__main__":
    main()

Add a dash of plot

Now that we have figured out how to generate SVGs, let us take it a notch higher by creating a web app using Dash. This gives us the ability to create a dashboard and load data on demand without having to re-run scripts.

Let us re-use the read_logs_files method and replace matplotlib with plotly

Finally, wrap it in a dash app.

import glob

import pandas as pd
import plotly.graph_objects as go
from dash import Dash, html, dcc, callback, Output, Input


def read_log_files(filetype):
    logs = []
    files = glob.glob(f"*_{filetype}.log") + glob.glob(f"*_{filetype}.*.log")
    print(f"Found {len(files)} {filetype} files")
    for file in files:
        df = pd.read_csv(file, header=None, names=["time", "value", "x", "y", "z"])
        df["time"] = (
            pd.to_numeric(df["time"], errors="raise") / 1000
        )  # Convert time to seconds
        df.attrs["name"] = "Queue Depth" + file.split(".")[1]
        logs.append(df)
    return logs


app = Dash()

options = ["lat", "bw", "iops", "clat"]
app.layout = [
    html.H1(children="Benchmark", style={"textAlign": "center"}),
    dcc.Graph(id="graph-content"),
    # Select option from the dropdown
    dcc.Dropdown(options, "iops", id="dropdown-selection"),
]


@callback(Output("graph-content", "figure"), Input("dropdown-selection", "value"))
def update_graph(value):
    list_of_dfs = read_log_files(value)
    fig_combined = go.Figure()
    for df in list_of_dfs:
        for col in df.columns:
            if col == "value":  # Value
                fig_combined.add_trace(
                    go.Scatter(
                        x=df["time"], y=df[col], mode="lines", name=df.attrs["name"]
                    )
                )
    fig_combined.update_layout(title_text="Benchmark")

    return fig_combined


if __name__ == "__main__":
    app.run(debug=True)

Here’s the app with a basic dropdown:

As you select the option, the app generates plot and displays them automatically.

That’s it for our fio plot app powered by Python!

With the power of Ollama and the ease of Tailscale VPN, you can host a private AI model server that is both accessible and secure, allowing for local chat, code assistance, and remote access from mobile devices.

Ollama

Let's start by installing Ollama, which helps serve LLM models. Install Ollama on the server machine using the official installer or system package managers. Then, download the models that are compatible with the machine. The latest Deepseek-R1 models, 7B and 8B, require 16 GB of memory and can run on a MacBook Pro. After installation, make sure Ollama is working:

# Choose the model that can run on your hardware
ollama run deepseek-r1:7b

Local AI code assitant

With the Ollama server running, you can use it for code assistance. You can use the open-source Continue plugin for VSCode or IntelliJ IDEs. To use the local LLM, you need to configure the config.json.

Interestingly, you can use Deepseek to modify the config JSON itself! Set the context with the config.json, the Deepseek model, and then prompt:

update file to use ollama with deepseek

Here’s a screenshot of the chat

Tailscale

Tailscale allows you to create software defined networks. This is a secure alternative to something like ngrok. Install Tailscale on the server and clients using the preferred method (e.g., Homebrew for macOS or package managers for Linux/Windows) or App Store. Login with your preferred auth service, e.g. Google is supported.

Connect Devices

If you do not want to use CLI, just visit the admin console to add devices. There are apps available for iOS, Android and other OS.

Remember to note down the IP or DNS hostname of the server machine and mobile devices.

Configure Ollama to Use Tailscale Server

# MacOS example 
launchctl setenv OLLAMA_HOST "<tailscale hostname>"
# Adjust port numbers as necessary based on your setup.

Access Models Across Devices

Ensure ollama is running:

ollama serve

Now, install ollama compatible app on the mobile device. Enchanted works well for iOS. In the settings, set ollama server as the tailscal IP/Hostname with the port 11434

Now, you can use the ollama model from the private server on the mobile device.

Getting started with Python should be easy, right? After all, most OS ship with a version of Python. However, most OS ship with a specific version on Python which they rely on to run services and scripts. The installed version may change after upgrades. It is recommended to not install packages system-wide. System Python is best managed by the OS.

Package Managers are cool

How should you install the Python version needed for development? Most OS ship with a package manager. Linux variants have yum, apt, dnf etc. MacOS users can install brew . Package managers fetch info from a repository and install the right version based on the OS variant, version and system architecture. This is a good way to start but it gets complicated to manage multiple Python versions. You may need different version to test compatibility or try new language features.

The download section for Python 3.12 lists 9 files. 2 are compressed source code and rest are installers covering major OS and architectures:

Notice that there is no installer for Linux. Perhaps, creating a universal installer for Windows and MacOS is easier. Linux distributions maintain their Python packages which are built from the source releases. Package managers can only install the versions available in the repository. This is important so that users only install stable versions.

There must be a better way

To install a dev or beta version, you either compile it from source or use a non-official package repo. You would agree that a single way to install released/dev versions would be convenient. One way to do so is using pyenv .

Pyenv

Pyenv helps install multiple Python versions (including release candidates, dev) and different implementations like pypy, stackless, pyston, etc. Start with the installation instructions here which depends on OS.

Usage

Once installed, you can search the available versions like this:

# Using 3.12 as an example as it has the least options right now
pyenv install -l | grep 3.12
  3.12.0rc2
  3.12-dev
  pypy2.7-7.3.12-src
  pypy2.7-7.3.12
  pypy3.9-7.3.12-src
  pypy3.9-7.3.12
  pypy3.10-7.3.12-src
  pypy3.10-7.3.12

Other common commands are:

• pyenv versions which lists installed versions

• pyenv global lets you manage the global Python version

• pyenv update works on Linux. On MacOS, this can be done with brew update

Removal is as easy as rm -rf ~/.pyenv/versions/"X.Y.Z" (Use -rf with caution). Less complicated than using system package manager to find and remove older Python versions.

Troubleshooting

Pyenv relies on the sources and compiles them on your machine. You may get errors in compilation if the required OS packages are not found. This is opposite of the convenience promised. This is the reason we discussed package managers and the challenges associated at the start. If you run into an issue, refer to common build problems.

Dependency Management

Pip Problems

Once you have a Python version installed, you need to manage projects. There are two problem:

1. Install a project specific Python version.

2. Manage the package dependencies.

There are many ways to create virtual environments, the simplest being python -m venv <name> . Dependencies can be managed by pip using a requirements.txt file. These are part of the standard Python library.

Things get complicated as the size of project and its dependencies increases. Most packages depend on other packages which are installed with them. Say, if you install PackageA, and it installs PackageB, PackageB. pip freeze will list all the installed packages. There's no easy way to separate top-level packages and you end up managing the requirements.txt file manually. Similarly, when packages need to be updated, there may be conflicts. As with all things Python, there are multiple solutions to managing dependencies.

Poetic Solutions

Poetry, also, solves these issues and provides a way to quick start new projects.

poetry new demo
Created package demo in demo
➜  demo cd demo 
➜  demo ls -lh
total 8
-rw-r--r--  1 manas  staff     0B Dec  9 14:14 README.md
drwxr-xr-x  3 manas  staff    96B Dec  9 14:14 demo
-rw-r--r--  1 manas  staff   257B Dec  9 14:14 pyproject.toml
drwxr-xr-x  3 manas  staff    96B Dec  9 14:14 tests
➜  demo cat pyproject.toml 
[tool.poetry]
name = "demo"
version = "0.1.0"
description = ""
authors = ["Your Name <you@example.com>"]
readme = "README.md"

[tool.poetry.dependencies]
python = "^3.12"


[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"

The pyproject.toml file is used to manage project and dependencies:

• poetry env manage virtualenvs.

• poetry add <package> installs packages

• poetry update will update dependencies

• You can organise packages in separate dependency groups like dev , docs, test. For example, IPython, ruff, rich, or black can be added to a dev group. While pytest can be in a test group. This helps you install only the required packages when creating containers or deploying code.

Read the docs, and explore all the features.

Note that both pyenv and poetry can be installed at system level while other things are at project level.

Code Quality

Lastly, if you code and care about code quality, use the following:

• Ruff is an extremely fast code linter and formatter, or Black

• Open source code analyser SonarQube Python for large projects

P.S. Get work done

Remember that the time spent in figuring out the best Linux distro, programming language (or paradigm), and package manager may not count as work.

Python has no compile step but you may continue to look for the best editor, typeface, and theme while the code is running.

When we transfer foreign currency, we look for the best exchange rates. Now, this rate changes daily and varies across banks. It is hard to predict the currency exchange rate but you can select the bank based on that day's rate.

Comparing daily rates

While, some services provide clear information about the rate and associated conversion fees. Indian banks like SBI and HDFC publish their daily forex rates in a PDF which makes it cumbersome to compare. As of today, Google will only show you a range of the rates.

This is an experiment to extract data from these PDFs and compare rates. To keep things simple, we will use only 2 banks. Also, we will assume the currency is USD. That means we will only look for TT Buy rates.

Environment Setup

This section assumes you have the recent Python 3.11 version installed and you are working in a virtualenv.

From your preferred package manager, install the following. I am using apt (Ubuntu) and pip (Python) here:

# System wide install
apt install ghostscript python3-tk

# Python packages
pip install camelot-py
pip install requests
pip install ghostscript

Check Package Installation

Let us import all these package to ensure they work.

# Check Ghostscript is installed
from ctypes.util import find_library
find_library("gs")

import camelot
import requests

Download Data

You can download the PDFs (search for bank forex rates) from the browser or copy the PDF url from the search results and then, use the code below. This may be cumbersome as some banks have a fixed URL while others change it daily but this this is the only manual step.

urls = {
    "sbi": "<insert PDF link here>",
    "hdfc":"<insert PDF link here>",
    # add other banks here
    }

# Download files as bank.pdf
for bank, file_url in urls.items():
    file_data = requests.get(file_url).content
    with open(f"{bank}.pdf", "wb") as file:
        file.write(file_data)

Now, we can extract the data we require. Camelot supports many formats. We will use pandas DataFrame throughout this experiment.

# Extracting a table from PDF is that easy
# Luckily, these PDFs are tabular
tables = camelot.read_pdf(f'sbi.pdf')

# There are many options to export this PDF
# We will use the Pandas DataFrame  
df = tables[0].df

Pandas but you can export to any other format. Pandas documentation is a great start to learn about the various selection methods.

# Now, we need to find the location of USD TT Buy
# Here's what I got from a bit of experimenting
# Skipping the verbose output of the entire PDF
print(df.iloc[[1, 2], [0, 2]]) 
                      0       2
1              CURRENCY  TT BUY
2  UNITED STATES DOLLAR   82.57

Let us store these locations in a dict and extract the values. Ideally, we should be able to use row labels instead of integers.

# Bank -> Location
banks = {
    "sbi": [[1, 2], [0, 2]],
    "hdfc": [[1, 21], [0, 6]]
}

def get_rate(bank: str):
    # Assumes files are placed in a same dir 
    tables = camelot.read_pdf(f'./{bank}.pdf')
    df = tables[0].df
    location = banks[bank]
    # Doesn't work with Python 3.10 or lower
    # Check Colab Notes
    usd_tt_buy = df.iloc[*location]
    return usd_tt_buy

# Display the rates
for bank in banks:
    rate = get_rate(bank)
    # Get a value from df
    usd = float(rate.iloc[1, 1])
    print(f"{bank.upper()} USD: {usd}")

That's it. Now this will display the rates for each bank.

Store data in a database

These rates are refreshed daily so, we should store them somewhere to analyse later. A good start would be a simple sqlite db. However, as we have DataFrame, we will use duckdb which provides options to ingress and export data in several formats. Let us see what it can do:

# Ensure duckdb is installed
import duckdb 

# Create a table in the database
with duckdb.connect("rates.db") as conn:
    conn.execute('''CREATE TABLE forex_rates_table (
        date DATE,
        bank VARCHAR,
        currency varchar,
        tt_buy DOUBLE)''')

As we are limited to 2 banks and 1 currency, we could hard-code them. This makes the examples much readable. Now, the only unknown is the rate.

To get values from the different DataFrames we have to figure out their location. After inspecting rates[0].columns where rates is a list of DataFrame , I found that the value is at [2][2] and [6][21] respectively. The integer indices are not ideal and could break the code in future. For example, SBI publishes different rates based on the amount to be transferred. This code is only using the rate from Page 1.

Let us insert these rows in the db to complete our experiment. We keep this data in a dict :

# Insert data

values = {
   "sbi": rates[0][2][2],
   "hdfc": rates[1][6][21]
}

with duckdb.connect("rates.db") as conn:
    currency = 'usd'
    for bank, rate in values.items():
        conn.execute('''INSERT INTO forex_rates_table VALUES (current_date, ?, ?, ?) ''',
                    [bank, currency, rate ])

Querying is simple too.

# Query Database Rows as DataFrame
with duckdb.connect("rates.db") as conn:
    result = conn.execute('SELECT * FROM forex_rates_table').fetch_df()

Note that the result is converted to DataFrame. This is helpful in a Jupyter/Colab Notebook as they support viewing data.

Notes on Google Colab

Google Colab is a great way to run code and analyse data. With all the extra batteries included, it comes with a few quirks too:

1. Some version camelot-py package does not work with the latest pypdf, so we need to explicitly install PyPDF2<3.0 using !pip install 'PyPDF2<3.0'

2. Python 3.10 does not allow usd = df.iloc[*loc]So, we need to be explicit. I tried to find a cleaner way but this works for now.

3. You have to install ghostscript using apt.

Also, you can use the following formatter to display DataFrame as a table:

from google.colab import data_table
data_table.enable_dataframe_formatter()

Conclusion

That completes our experiment. We have created a way to collect forex rates and store them in a database. Here we learned:

• PDF parsing with camelot-py

• Using pandas DataFrame and data selection

• Creating a simple DuckDB database

• Experimenting with Google Colab.

Next, we can deploy this code to run daily and expose it through an API. You can try a working example in this Colab Notebook or see output at GitHub

Object-oriented programming cannot be explained without abstraction. Beyond that also It is one of the key principles when building software. While it is important to understand and utilize abstraction, it can get in the way of understanding internals. After all, abstractions are put in place to hide details.

In Python, objects are the abstraction for data. To understand them better, we will have to break through this abstraction layer. Observing the behaviour of Python objects is a good start but we need to dive deeper.

Commonly, these concepts are explained by creating classes for cars, animals, or shapes. Here, we won't do that. Instead, we will use the built-in Python types like int and list only.

Code

CPython implementation

We start by taking a look at how CPython implements objects:

typedef struct _object PyObject;

Since AI gets to do the boring work these days, let us ask Cody to explain _object:

The _object struct defines the basic structure of all Python objects. It contains:

• _PyObject_HEAD_EXTRA: Extra space for additional fields in debug builds.

• ob_refcnt: The reference count field. This is used to track when the object can be deallocated.

• ob_type: A pointer to the object's type object. This defines the object's type and its methods.

So in summary, _object defines the basic fields that are common to all Python objects - their reference count and type information.

More specific object types (like lists, dicts, etc.) build upon this basic _object struct by extending it with additional fields. But they always keep these core fields to maintain memory management and type information.

Adventure with objects

Now, that you have seen the basic structure, let us take help from rich to see this in action. You can install and import rich as below:

# Install rich with your favourite package manager
# Replace the default print and inspect
from rich import print
from rich import inspect

Notice the 23 attributes that are not shown, use inspect(object, all=True to see them all. This was still abstract but you get the idea. Now, let us work with actual objects.

Python object has an identity, a type and a value

We can inspect the id, class and value of objects. Here's an example of int:

Objects have many interesting properties, most importantly:

• 💡

  An object’s identity never changes once it has been created

Question for beginners: Which one is the object here, x or 1? The answer lies in id(x) which is the memory address.

• 

  * There are ways to do this assuming you know what you are doing. However, it isn't easy when there are so many ways to shoot yourself in the foot.

• 

  Notice that y is a reference to a list (a mutable type). Objects whose value cannot be changed are called immutable. Understanding this distinction can save you from a lot of trouble. No wonder, mutable arguments made it to the top of common gotchas.

• Python wouldn't be fun if we couldn't change values. Without mutability, this would be an adventure in functional programming with Lisp or Haskell.

That's a wrap on Python objects. Now you know how to inspect id, type and values. All the code is here as a notebook:

Over time, we all end up with a collection of scripts tucked away in a scripts directory or git repo. Often these are written for a specific purpose and do not belong to a single category. In my case, I have Python scripts that configure infra, check for pre-requisite in clusters, generate data, query internal APIs and more. My teammates have their collection and other teams must have theirs too.

Scripts can become complex to run with many args while remaining trivial to be turned into full-fledged apps.

Fundamentally, they takeinput as args, perform actions and return an output.This is where Windmill shines. It generates UI which can be deployed as app using only the code. If you are concerned about running code on the cloud app, you can self-host on a Kubernetes cluster.

Here's my experience deploying Windmill on Kubernetes.

Windmill

Windmill docs are pretty good and straightforward. Helm chart makes it easy to deploy. You can start with minikube and then try on Kubernetes.

Preparation

Configure External database

It is better to have a hosted database instance ready in advance. You can disable the default postgresql in values.yaml, minio is also optional. However, ensure the database is configured correctly before proceeding. Otherwise, app pods will end up in a crashloop (as the docs mention). The database credentials are not secret but try to use sslmode=require.

Configure Ingress

The default ingress works well on minikube but you need to configure Ingress as per your k8s. Remember to setbaseDomain and baseProtocol (http to https) accordingly.

Workaround for private registry

If your k8s cannot access ghcr.io/windmill-labs registry then you can copy the images to a private registry. Luckily, they use only 2 images (as of version 1.109)

# <tag> should be same as release.
docker pull ghcr.io/windmill-labs/windmill:<tag>
docker pull ghcr.io/windmill-labs/windmill-lsp:<tag>
# Now tag and push them to the private registry

This is not ideal but a workaround if you are out of options. Next, clone the helm chart and replace these image: values. You can install this chart:

❯ cd windmill-helm-charts
❯ helm install mywindmill ./charts/windmill

You can also use a private pipIndexUrl This would speed up Python code execution, as the script installs required packages.

Deployment

Deployment is easy as the docs say:

# add the Windmill helm repo
helm repo add windmill https://windmill-labs.github.io/windmill-helm-charts/
# install chart with default values
helm install windmill-chart windmill/windmill  \
      --namespace=windmill \
      --create-namespace

Navigate to URL and login with admin@windmill.dev / changeme

Generate UI from code

Start with a sample script which has a main function like this:

def main(
    no_default: str,
    #db: postgresql,
    name="Nicolas Bourbaki",
    age=42,
    obj: dict = {"even": "dicts"},
    l: list = ["or", "lists!"],
    file_: bytes = bytes(0),
):

Arguments to main are used to generate UI elements based on the type. On execution, imported packages are installed. All print or log statements are displayed in a log section and return values are shown in output.

Each script gets a unique path and you can see execution history, re-use previous inputs, and even schedule runs.

The Web IDE provides a decent editing experience. For Python, support for assistants (Pyright, Black, Ruff) helps keep the code clean.

Advanced Features

Auto-generated UI is one of the features of Windmill. It can create complex Workflow and comes with a decent drag-and-drop App builder. However, the code is the basic building block.

Conclusion

Windmill is an awesome open-source option to turn code into apps with reasonable deployment and configuration options. However, I could not find an easy way to enable authentication without using oauth integrations (which may be plenty for most people). Many integrations might work better out of the box in the cloud app.

The promise of writing code that will run on multiple platforms is not new. There have been many runtimes, languages, frameworks and platforms built to solve this problem. The abstraction level varies. Here, we look above the hypervisor and OS layers.

Web browsers were built to render HTML, which is a standard. Yet, different implementations caused much pain and anguish to developers. JVM (Java Virtual Machine) runs apps written in Java (and other languages), on several devices. Though it is still widely used, it could not conquer the web.

On the web, there was a time when games and other rich content were written in Flash. It was a runtime which delivered the same experience on supported browsers. Alas, it was a source of several security bugs and was eventually discontinued.

In mobile development, there are many cross-platform frameworks. The idea remains the same: code that runs on multiple OS. Today, many frameworks target web and native devices both. There are many such examples.

Most recently, Web Assembly (Wasm) provides a way to run code written in multiple languages on the web at near-native speed, with client apps running on the web that previously couldn't have done so.

Web Assembly

Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications. Apart from portability, it has other goals like efficiency, safety, high performance, etc.

Let us take a look at portability. It can be run on Web and Non-web environments. We will not be compiling to wasm or dealing with any wasm code. Instead, we will use it to run a complete development environment in the browser.

Starters: Web

Pyodide runs Python in the browser powered by Wasm. It can be used as a kernel to run Jupyter notebooks using Jupyterlite. Here's how you can run it locally

Assuming you have Python and a virtualenv, create a project dir, say python-wasm. Create a requirements.txt file:

jupyterlite-core
jupyterlite-pyodide-kernel
ipywidgets

Install the requirements and run

# Install requirements
python -m pip install -r requirements.txt
# Create a Jupyterlite site
jupyter lite build --output-dir dist
# Run
jupyter lite serve

Open the link displayed in the output:

 Serving JupyterLite Debug Server from:
            /Users/python-wasm/workers/public/_output
        on:
            http://127.0.0.1:8000/index.html

And you can run (almost) any Python code! You may be able to interact with the notebook as long as the content is cached in the browser storage but changes do not persist across sessions.

Another interesting project is CPython Wasm. We can run sqlite, Postgres, and even Wordpress!

Entrée: Non-Web

Wasm can be run beyond the web. It can be run from docker containers, directly using the various runtimes, at the edge and more.

Let us try an interesting project Wasm Workers Server which can be installed easily:

# Install runtime
curl -fsSL https://workers.wasmlabs.dev/install | bash

Now, we can run workers in multiple languages using this runtime. But wait ...

Dessert: Best of both

We already have a Jupyterlite site (which runs on wasm) and now, a wasm runtime. Why not integrate these two?

Wasm Workers Server (wws) is capable of serving static content. So, let us run the Jupyterlite using wws

In the python-wasm dir, create another dir public and move the dist dir there.

# Project structure will look like
 └── python-wasm
    └── public
        └── dist

# Install the wws Python module
cd python-wasm
wws runtimes install python latest

# Run the server
wws
❯ wws
⚙️  Loading routes from: .                                                                                                                                             ─╯
🗺  Detected routes:
    - http://127.0.0.1:8080/
      => ./index.py
🚀 Start serving requests at http://127.0.0.1:8080

Now your Jupyterlite site is accessible at http://127.0.0.1:8080/dist/

Now, this is entirely powered by Web Assembly!

Here's the code on Replit:

There are several network scanners and tools that let you find out open ports. This is a demonstration of using socket, ipaddress and asyncio to check ports concurrently.

Basic Check

A basic check can be written using socket module:

with socket.socket(family, sock_type) as s:
        result = s.connect_ex(address)

For our example, we will only support the following:

• family: AF_INET for IPv4, AF_INET6 for IPv6

• sock_type : SOCK_STREAM for TCP, SOCK_DGRAM for UDP

Notice, we use connect_ex as it returns an error indication instead of raising exceptions. Now, let us create a function check_port that accepts a server IP address, port and port type and returns the result 0 if success

def check_port(server: str, port: int, port_type: str) -> int:
    """Check whether a port is open or not
    :param server: IP Address 
    :param port: Port number
    :param port_type: Port Type
    :return: 0 if successful, err code no.
    """
    if port_type == "TCP":
        sock_type = socket.SOCK_STREAM
    elif port_type == "UDP":
        sock_type = socket.SOCK_DGRAM
    else:
        raise ValueError("Port type should be TCP or UDP")
    # validate the address
    ip_address = ipaddress.ip_address(server)
    if ip_address.version == 4:
        family = socket.AF_INET
    else:
        family = socket.AF_INET6
    location = (server, port)
    # It helps to track the time 
    start = time.perf_counter_ns()
    with socket.socket(family, sock_type) as a_socket:
        # timeouts saves us from a forever blocking loop
        a_socket.settimeout(TIMEOUT)
        result = a_socket.connect_ex(location)
        a_socket.close()
    end = time.perf_counter_ns() - start
    return result

Run concurrently with asyncio

We should be able to run this against multiple addresses and ports. The obvious way to achieve this is to pass a list of ports and addresses and execute the logic in a loop. This would a serial approach. The time taken by this execution will be the sum of all the checks. This does not sound optimal.

The next option is to run these checks concurrently. We have already added a timeout to ensure that the time does not exceed TIMEOUT

So, let us use asyncio to run this function concurrently.

import asyncio
import ipaddress
import socket
import time

from rich.progress import track

SERVERS = []
# List of ports to check
TCP_PORTS = [53, 389, 445]
UDP_PORTS = [3268, 636, 185]
TIMEOUT = 2

async def main():
    for server in track(SERVERS, description="Checking..."):
        rows = await asyncio.gather(
            *[asyncio.to_thread(check_port, server, port, "UDP") for port in UDP_PORTS],
            *[asyncio.to_thread(check_port, server, port, "TCP") for port in TCP_PORTS],
        )

if __name__ == "__main__":
    s = time.perf_counter()
    asyncio.run(main())
    elapsed = time.perf_counter() - s
    print(f"Executed in {elapsed:0.2f} seconds.")

Now, let us breakdown the code to understand it better:

asyncio.to_thread runs the function in a separate thread. So, we run a separate thread for each port. asyncio.gather runs these threads, which are awaitable objects, concurrently. To illustrate that multiple threads can be passed to gather, we have separated UDP and TCP.

We wrap all this logic in async def main() which itself is run by asyncio.run(main())

Rich Table Output

Next, we print the out in a formatted table using the amazing rich package

import asyncio
import ipaddress
import socket
import time

from rich.console import Console
from rich.progress import track
from rich.table import Table

SERVERS = []

TCP_PORTS = [53, 389, 445, 3268, 636]
UDP_PORTS = [3268, 636, 185]
TIMEOUT = 2

# Rich Table
console = Console()
table = Table(title="Results")
table.add_column("Server", justify="left")
table.add_column("Type", justify="left")
table.add_column("Port", justify="left")
table.add_column("Status", justify="left")
table.add_column("Time (ns)", justify="right")


def check_port(server: str, port: int, port_type: str) -> dict:
    """Check whether a port is open or not
    :param server: IP address
    :param port: Port number
    :param port_type: Port Type
    :return: rich table row as dict
    """
    if port_type == "TCP":
        sock_type = socket.SOCK_STREAM
    elif port_type == "UDP":
        sock_type = socket.SOCK_DGRAM
    else:
        raise ValueError("Port type should be TCP or UDP")
    ip_address = ipaddress.ip_address(server)
    if ip_address.version == 4:
        family = socket.AF_INET
    else:
        family = socket.AF_INET6

    location = (server, port)
    start = time.perf_counter_ns()
    with socket.socket(family, sock_type) as a_socket:
        a_socket.settimeout(TIMEOUT)
        result_of_check = a_socket.connect_ex(location)
        a_socket.close()
    end = time.perf_counter_ns() - start
    # Result to rich format
    if result_of_check == 0:
        return {
            "row": [server, port_type, str(port), "OPEN", f"{end:0.2f}"],
            "style": "green",
        }
    else:
        return {
            "row": [server, port_type, str(port), "CLOSED", f"{end:0.2f}"],
            "style": "red",
        }

async def main():
    for server in track(SERVERS, description="Checking..."):
        rows = await asyncio.gather(
            *[asyncio.to_thread(check_port, server, port, "UDP") for port in UDP_PORTS],
            *[asyncio.to_thread(check_port, server, port, "TCP") for port in TCP_PORTS],
        )
        [table.add_row(*r["row"], style=r["style"]) for r in rows]


if __name__ == "__main__":
    s = time.perf_counter()
    asyncio.run(main())
    console.print(table)
    elapsed = time.perf_counter() - s
    print(f"Executed in {elapsed:0.2f} seconds.")

Now, let us understand what's happening here.

The rows are appended to the rich table for each server. Once the asyncio loop is finished, we display the table using console.print(table)

Here's the output of the program run against Google's public DNS IPs.

The progress bar is displayed by the track method in rich.progress

Fork it on Replit

The entire program can be run from the Replit. Feel free to fork it.

WARNING: Please run this program responsibly, it is meant to be a demo only. Port scanning can be considered malicious activity.