Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Dev-in-a-Box

Minimal evaluation site with no compute services

Intro

To get familiar with the setup procedures for chi-in-a-box, or to develop services, you can follow this (very) minimal setup guide.

Note: This doesn't include support for TLS, or for communication outside of the single controller node. Services will be accessed via SSH tunnel or similar method.

Prerequisites:

Baremetal or Virtual Machine with 8 cores, 16gb ram, 80gb disk. This is roughly double the minimum for just control-plane services, as we will also be using these resources to host "virtual" baremetal nodes.

You must have a user account on the machine with passwordless sudo.

If launching a VM on Chameleon to host this, follow the following steps.

  1. Launch an instance on KVM flavor: m1.xlarge image: CC-Ubuntu20.04 network: sharednet1

  2. Attach a floating IP

  3. Allow SSH via the floating IP (by applying the appropriate security group)

  4. SSH into the node as cc@floating-ip

Installation

  1. Prepare a working directory. We use /opt by convention. It must be writable by your current user.

    cd /opt
sudo chown cc:cc /opt

  2. Clone the chi-in-a-box repo, install, and initialize your site-configuration

    git clone https://github.com/ChameleonCloud/chi-in-a-box
cd chi-in-a-box
./cc-ansible --site /opt/site-config/ init

  3. export an env var so you don't need to type "--site" for the remaining commands

    export CC_ANSIBLE_SITE=/opt/site-config/

  4. Create some veth-pairs to act as "dummy" network interfaces.

    External API interface

    sudo ip link add name ext_api_veth type veth peer ext_api_vethb
sudo ip addr add 192.168.100.2/24 dev ext_api_veth
sudo ip link set ext_api_veth up
sudo ip link set ext_api_vethb up

    Internal API interface

    sudo ip link add name int_api_veth type veth peer int_api_vethb
sudo ip addr add 10.10.10.2/24 dev int_api_veth
sudo ip link set int_api_veth up
sudo ip link set int_api_vethb up

    Neutron Provider Network interfaces

    sudo ip link add name physnet1_veth type veth peer physnet1_vethb
sudo ip link set physnet1_veth up
sudo ip link set physnet1_vethb up

sudo ip link add name physnet2_veth type veth peer physnet2_vethb
sudo ip link set physnet2_veth up
sudo ip link set physnet2_vethb up

sudo ip link add name physnet3_veth type veth peer physnet3_vethb
sudo ip link set physnet3_veth up
sudo ip link set physnet3_vethb up

    We also want to make sure these intefaces aren't filtered by any firewalls. If you're using firewalld, then the following commands will do it:

    Here, ens3 is our external facing interface, so we don't want to keep it firewalled for safety, but open up everything else.

    sudo firewall-cmd --zone=public --add-interface=ens3
sudo firewall-cmd --set-default-zone trusted

  5. In your site-config, replace defaults.yml with the one for dev-in-a-box

    cp /opt/site-config/dev-in-a-box.yml /opt/site-config/defaults.yml

  6. Bootstrap the controller node, this will install apt packages, configure Docker, and modify /etc/hosts

    ./cc-ansible bootstrap-servers

  7. Run prechecks to ensure common issues are avoided.

    ./cc-ansible prechecks

    • this will probably yell about nscd.service. If so, run the following, then rerun prechecks.

      sudo systemctl disable --now nscd.service

  8. At this point, we should be ready to "deploy".

    ./cc-ansible deploy

    Deploy is a composite action, executing the following sub-actions:

    • pull: download relevant docker container images.

      Deploy will not pull newer images if one is in the cache already. You can execute pull directly if you need to explicitly pull a newer version.

    • genconfig: template and copy config files into /etc/kolla, but don't restart services to apply yet

      This will combine the upstream defaults, contents of chi-in-a-box, and your site-config, and template config files into /etc/kolla/<service_name>. If you've added additional configuration, this step can warn you about invalid or missing config values, before actually modifying any running containers. Even if the step passes, you may want to inspect files under /etc/kolla/ to make sure they match your expectations.

    • deploy-containers: check and if necessary update running containers. This can be run separately if you want to make sure containers are running, but explicitly don't want to touch the templated configuration, for example if you've made edits to your site config, or temporary changes directly in /etc/kolla.

  9. If all the steps so far have passed, all the core services should now be running! However, this isn't everything needed for a useful cloud. post-deploy consists of all the steps that require a functioning control plane. These include:

    • Creating default networks

    • Creating compute "flavors"

    • Uploading default disk images for users to use

    • Installing various hammers and other utility services/cron-jobs. To run this step, execute:

    ./cc-ansible post-deploy

  10. Now, we'll create some "virtual" baremetal nodes, used to test out the site. These are just VMs run with libvirt, but are configured via IPMI and pxe network booted like a baremetal node, so we can exercise Ironic. The following playbook will install and configure the tenks utility to accomplish this. At the end of the invocation, it will print out some commands for you to run yourself to finish the setup.

  1. Run the commands to bring up tenks. They will look something like the following, but may vary if you've changed your site-config from what's included here.

Once it's finished, we'll need to add an IP address to the bridge it attached for the ironic-provisioning network.

  1. At this point, it should all be up and running! Try out one of the "baremetal nodes"

    • openstack baremetal node list

    • let's trigger an inspection.

    • to see what's happening on the controller:

    • once you see a line like

      Successfully set node 44d0ac06-77d6-4444-93ce-7c8db5b54fff power state to power on by power on.

      this means that the VM has been successfully "powered on".

    • to watch the machine's "serial console", execute:

      Note: to exit this shell, press ctrl+]

  2. Download some real images to use! To avoid downloading "all" the images, we'll manually invoke the chameleon image download tool.

    After a little while, you'll start seeing images like CC-Ubuntu22.04 in the output of openstack image list

  3. Lets launch a real instance. NOTE!: At this point, we've configured the node in ironic, but NOT in blazar, so we can launch instances without a reservation.

    • Our node should have finished inspection, so we'll need to move it from manageable back to available

    • Now that it's "available", we can launch a server on it.

      If you access the console again via sudo virsh console tk0, you should see the image get written to disk, then the VM reboot into the final image.

  4. Access your site! You can access it by the following methods:

    1. All services are listening on the haproxy VIP on "ext_api_veth" interface, so you need a way to get to 192.168.100.0/24. We recommend using sshuttle on your local machine, invoked as: sshuttle -r cc@<floating_ip_address> 192.168.100.0/24

    2. HAProxy and thus Horizon are listening on 192.168.100.254:80, which you can access after starting sshuttle. The username is admin, and the password can be viewed by running the following command:

    3. You can use the Openstack CLI or API directly. The CLI tools are pre-installed in the chi-in-a-box virtualenv, and the admin credentials in an admin-openrc file in your site-config directory. Access the tools as follows:

PreviousVerification ChecklistNextEdge-in-a-Box

Last updated