{"id":50385050,"url":"https://github.com/stackhpc/a-universe-from-nothing","last_synced_at":"2026-05-30T14:30:56.050Z","repository":{"id":38180445,"uuid":"177842218","full_name":"stackhpc/a-universe-from-nothing","owner":"stackhpc","description":"Kayobe configuration for the Kayobe workshop \"A Universe from Nothing: Containerised OpenStack deployment using Kolla, Ansible and Kayobe\"","archived":false,"fork":false,"pushed_at":"2026-02-02T22:01:56.000Z","size":675,"stargazers_count":95,"open_issues_count":19,"forks_count":28,"subscribers_count":10,"default_branch":"stable/2025.1","last_synced_at":"2026-02-03T02:13:29.307Z","etag":null,"topics":["ansible","kayobe","kolla","kolla-ansible","openstack"],"latest_commit_sha":null,"homepage":"https://docs.openstack.org/kayobe/latest/","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/stackhpc.png","metadata":{"files":{"readme":"README.rst","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2019-03-26T17:59:20.000Z","updated_at":"2026-01-15T14:39:03.000Z","dependencies_parsed_at":"2023-10-04T05:35:47.309Z","dependency_job_id":"d727e91b-bd68-4fb2-9f3f-3f5470261e42","html_url":"https://github.com/stackhpc/a-universe-from-nothing","commit_stats":null,"previous_names":[],"tags_count":101,"template":false,"template_full_name":null,"purl":"pkg:github/stackhpc/a-universe-from-nothing","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stackhpc%2Fa-universe-from-nothing","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stackhpc%2Fa-universe-from-nothing/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stackhpc%2Fa-universe-from-nothing/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stackhpc%2Fa-universe-from-nothing/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/stackhpc","download_url":"https://codeload.github.com/stackhpc/a-universe-from-nothing/tar.gz/refs/heads/stable/2025.1","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stackhpc%2Fa-universe-from-nothing/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":33696681,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-05-30T02:00:06.278Z","response_time":92,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["ansible","kayobe","kolla","kolla-ansible","openstack"],"created_at":"2026-05-30T14:30:55.641Z","updated_at":"2026-05-30T14:30:56.024Z","avatar_url":"https://github.com/stackhpc.png","language":"Shell","funding_links":[],"categories":[],"sub_categories":[],"readme":"======================================================================================================================\nKayobe Configuration for \"A Universe from Nothing: Containerised OpenStack deployment using Kolla, Ansible and Kayobe\"\n======================================================================================================================\n\nThis repository may be used as a workshop to configure, deploy and\nget hands-on with OpenStack Kayobe.\n\nIt provides a configuration and walkthrough for the `Kayobe\n\u003chttps://docs.openstack.org/kayobe/latest/\u003e`__ project based on the\nconfiguration provided by the `kayobe-config\n\u003chttps://opendev.org/openstack/kayobe-config\u003e`__ repository.\nIt deploys a containerised OpenStack environment using Kolla, Ansible and\nKayobe.\n\nSelect the Git branch of this repository for the OpenStack release you\nare interested in, and follow the README.\n\nRequirements\n============\n\nFor this workshop, we require the use of a single server, configured as a\n*seed hypervisor*. This server should be a bare metal node or VM running\nUbuntu Noble or Rocky 9, with the following minimum requirements:\n\n* 64GB RAM (more is recommended when growing the lab deployment)\n* 100GB disk\n\nWe will also need SSH access to the seed hypervisor, and passwordless sudo\nconfigured for the login user.\n\nExercise\n========\n\nOn the seed hypervisor, we will deploy three VMs:\n\n* 1 seed\n* 1 controller\n* 1 compute node\n\nThe seed runs a standalone Ironic service. The controller and compute node\nare 'virtual bare metal' hosts, and we will use the seed to provision them\nwith an OS. Next we'll deploy OpenStack services on the controller and\ncompute node.\n\nAt the end you'll have a miniature OpenStack cluster that you can use to test\nout booting an instance using Nova, access the Horizon dashboard, etc.\n\nUsage\n=====\n\nThere are four parts to this guide:\n\n* `Preparation`_\n* `Deploying a Seed`_\n* `A Universe from a Seed`_\n* `Next Steps`_\n\n*Preparation* has instructions to prepare the seed hypervisor for the\nexercise, and fetching the necessary source code.\n\n*Deploying a Seed* includes all instructions necessary to download and install\nthe Kayobe prerequisites on a plain Rocky 9 or Ubuntu Jammy cloud image,\nincluding provisioning and configuration of a seed VM. Optionally, snapshot the\ninstance after this step to reduce setup time in the future.\n\n*A Universe from a Seed* contains all instructions necessary to deploy from\na host running a seed VM. An image suitable for this can be created\nvia `Optional: Creating a Seed Snapshot`_.\n\nOnce the control plane has been deployed see `Next Steps`_ for\nsome ideas for what to try next.\n\nPreparation\n-----------\n\nThis shows how to prepare the seed hypervisor for the exercise. It assumes you\nhave created a seed hypervisor instance fitting the requirements above and have\nalready logged in (e.g. ``ssh rocky@\u003cip\u003e``, or ``ssh ubuntu@\u003cip\u003e``).\n\n.. code-block:: console\n\n   # Install git and tmux.\n   if $(which dnf 2\u003e/dev/null \u003e/dev/null); then\n       sudo dnf -y install git tmux\n   else\n       sudo apt update\n       sudo apt -y install git python3 python3-venv tmux\n   fi\n\n   # Install Python 3.12 on Rocky Linux 9\n   if $(which dnf 2\u003e/dev/null \u003e/dev/null); then\n       sudo dnf -y install python3.12\n   fi\n\n   # Disable the firewall.\n   sudo systemctl is-enabled firewalld \u0026\u0026 sudo systemctl stop firewalld \u0026\u0026 sudo systemctl disable firewalld\n\n   # Put SELinux in permissive mode both immediately and permanently.\n   if $(which setenforce 2\u003e/dev/null \u003e/dev/null); then\n       sudo setenforce 0\n       sudo sed -i 's/^SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config\n   fi\n\n   # Prevent sudo from performing DNS queries.\n   echo 'Defaults  !fqdn' | sudo tee /etc/sudoers.d/no-fqdn\n\n   # Import existing network configuration in systemd-networkd. This prevents\n   # existing netplan configuration (e.g. for a DHCP-configured interface) from\n   # being disabled by kayobe.\n   if command -v apt \u003e/dev/null 2\u003e\u00261; then\n       sudo find /run/systemd/network -mindepth 1 -maxdepth 1 -exec cp -t /etc/systemd/network/ {} +\n       sudo find /etc/systemd/network -mindepth 1 -maxdepth 1 -exec chown root:systemd-network {} +\n   fi\n\n   # Optional: start a new tmux session in case we lose our connection.\n   tmux\n\n   # Start at home.\n   cd\n\n   # Clone Beokay.\n   [[ -d beokay ]] || git clone https://github.com/stackhpc/beokay.git\n\n   # Use Beokay to bootstrap your control host.\n   if $(which dnf 2\u003e/dev/null \u003e/dev/null); then\n       PYTHON_ARG=\" --python /usr/bin/python3.12\"\n   else\n       PYTHON_ARG=\"\"\n   fi\n   [[ -d deployment ]] || beokay/beokay.py create --base-path ~/deployment --kayobe-repo https://opendev.org/openstack/kayobe.git --kayobe-branch stable/2025.1 --kayobe-config-repo https://github.com/stackhpc/a-universe-from-nothing.git --kayobe-config-branch stable/2025.1 $PYTHON_ARG\n\n   # Clone the Tenks repository.\n   cd ~/deployment/src\n   [[ -d tenks ]] || git clone https://opendev.org/openstack/tenks.git\n   cd\n\n   # Configure host networking (bridge, routes \u0026 firewall)\n   ~/deployment/src/kayobe-config/configure-local-networking.sh\n\nDeploying a Seed\n----------------\n\nThis shows how to create an image suitable for deploying Kayobe. It assumes you\nhave created a seed hypervisor instance fitting the requirements above and have\nalready logged in (e.g. ``ssh rocky@\u003cip\u003e``, or ``ssh ubuntu@\u003cip\u003e``), and\nperformed the necessary `Preparation`_.\n\n.. code-block:: console\n\n   # If you have not done so already, activate the Kayobe environment, to allow\n   # running commands directly.\n   source ~/deployment/env-vars.sh\n\n   # Configure the seed hypervisor host.\n   kayobe seed hypervisor host configure\n\n   # Provision the seed VM.\n   kayobe seed vm provision\n\n   # Configure the seed host, and deploy a local registry.\n   kayobe seed host configure\n\n   # Pull, retag images, then push to our local registry.\n   ~/deployment/src/kayobe-config/pull-retag-push-images.sh\n\n   # Deploy the seed services.\n   kayobe seed service deploy\n\n   # Deploying the seed restarts networking interface,\n   # run configure-local-networking.sh again to re-add routes.\n   ~/deployment/src/kayobe-config/configure-local-networking.sh\n\n   # Optional: Shutdown the seed VM if creating a seed snapshot.\n   sudo virsh shutdown seed\n\nIf required, add any additional SSH public keys to ~/.ssh/authorized_keys\n\nOptional: Creating a Seed Snapshot\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nIf necessary, take a snapshot of the hypervisor instance at this point to speed up this\nprocess in the future.\n\nYou are now ready to deploy a control plane using this host or snapshot.\n\nA Universe from a Seed\n-----------------------------\n\nThis shows how to deploy a control plane from a VM image that contains a\npre-deployed seed VM, or a host that has run through the steps in\n`Deploying a Seed`.\n\nHaving a snapshot image saves us some time if we need to repeat the deployment.\nIf working from a snapshot, create a new instance with the same dimensions as\nthe Seed image and log into it.\nOtherwise, continue working with the instance from `Deploying a Seed`_.\n\n.. code-block:: console\n\n   # Optional: start a new tmux session in case we lose our connection.\n   tmux\n\n   # Configure non-persistent networking, if the node has rebooted.\n   ~/deployment/src/kayobe-config/configure-local-networking.sh\n\nMake sure that the seed VM (running Bifrost and supporting services)\nis present and running.\n\n.. code-block:: console\n\n   # Check if the seed VM is present and running.\n   sudo virsh list --all\n\n   # Start up the seed VM if it is shut off.\n   sudo virsh start seed\n\nWe use the `TENKS project \u003chttps://www.stackhpc.com/tenks.html\u003e`_ to model\nsome 'bare metal' VMs for the controller and compute node.  Here we set up\nour model development environment, alongside the seed VM.\n\n.. code-block:: console\n\n   # Set Environment variables for Kayobe dev scripts\n   export KAYOBE_CONFIG_SOURCE_PATH=~/deployment/src/kayobe-config\n   export KAYOBE_VENV_PATH=~/deployment/venvs/kayobe\n   export TENKS_CONFIG_PATH=~/deployment/src/kayobe-config/tenks.yml\n\n   # Use tenks to deploy the overcloud machines\n   ~/deployment/src/kayobe/dev/tenks-deploy-overcloud.sh ~/deployment/src/tenks\n\n   # Activate the Kayobe environment, to allow running commands directly.\n   source ~/deployment/env-vars.sh\n\n   # Inspect and provision the overcloud hardware:\n   kayobe overcloud inventory discover\n   kayobe overcloud hardware inspect\n   kayobe overcloud introspection data save\n   kayobe overcloud provision\n\nConfigure and deploy OpenStack to the control plane\n(following `Kayobe host configuration documentation \u003chttps://docs.openstack.org/kayobe/latest/deployment.html#id3\u003e`_):\n\n.. code-block:: console\n\n   kayobe overcloud host configure\n   kayobe overcloud container image pull\n   kayobe overcloud service deploy\n   source ~/deployment/src/kayobe-config/etc/kolla/public-openrc.sh\n   kayobe overcloud post configure\n\nAt this point it should be possible to access the Horizon GUI via the\nserver's public IP address, using port 80 (achieved through port\nforwarding to the controller VM).  Use the admin credentials from\n``OS_USERNAME`` and ``OS_PASSWORD`` to get in.\n\nThe following script will register some resources (keys, flavors,\nnetworks, images, etc) in OpenStack to enable booting up a tenant\nVM:\n\n.. code-block:: console\n\n   source ~/deployment/src/kayobe-config/etc/kolla/public-openrc.sh\n   ~/deployment/src/kayobe-config/init-runonce.sh\n\nFollowing the instructions displayed by the above script, boot a VM.\nYou'll need to have activated the `~/deployment/venvs/os-venv` virtual environment.\n\n.. code-block:: console\n\n   source ~/deployment/venvs/os-venv/bin/activate\n   openstack server create --image cirros \\\n             --flavor m1.tiny \\\n             --key-name mykey \\\n             --network demo-net demo1\n\n   # Assign a floating IP to the server to make it accessible.\n   openstack floating ip create public1\n   fip=$(openstack floating ip list -f value -c 'Floating IP Address' --status DOWN | head -n 1)\n   openstack server add floating ip demo1 $fip\n\n   # Check SSH access to the VM.\n   ssh cirros@$fip\n\n   # If the ssh command above fails you may need to reconfigure the local\n   networking setup again:\n   ~/deployment/src/kayobe-config/configure-local-networking.sh\n\n*Note*: when accessing the VNC console of an instance via Horizon,\nyou will be sent to the internal IP address of the controller,\n``192.168.33.2``, which will fail. Open the console-only display link\nin new broser tab and replace this IP in the address bar with\nthe public IP of the hypervisor host.\n\nThat's it, you're done!\n\nNext Steps\n-----------------------------\n\nHere's some ideas for things to explore with the deployment:\n\n* **Access Control Plane Components**: take a deep dive into the internals\n  by `Exploring the Deployment`_.\n* **Deploy OpenSearch and OpenSearch Dashboards**: see `Enabling Centralised Logging`_\n  to get logs aggregated from across our OpenStack control plane.\n\nExploring the Deployment\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nOnce each of the VMs becomes available, they should be accessible via SSH as\nthe ``rocky``, ``ubuntu`` or ``stack`` user at the following IP addresses:\n\n===========  ================\nHost         IP\n===========  ================\nseed         ``192.168.33.5``\ncontroller0  ``192.168.33.3``\ncompute0     ``192.168.33.6``\n===========  ================\n\nThe control plane services are run in Docker containers, so try\nusing the docker CLI to inspect the system.\n\n.. code-block:: console\n\n    # List containers\n    docker ps\n    # List images\n    docker images\n    # List volumes\n    docker volume ls\n    # Inspect a container\n    docker inspect \u003ccontainer name\u003e\n    # Execute a process in a container\n    docker exec -it \u003ccontainer\u003e \u003ccommand\u003e\n\nThe kolla container configuration is generated under ``/etc/kolla`` on\nthe seed and overcloud hosts - each container has its own directory\nthat is bind mounted into the container.\n\nLog files are stored in the ``kolla_logs`` docker volume, which is\nmounted at ``/var/log/kolla`` in each container. They can be accessed\non the host at ``/var/lib/docker/volumes/kolla_logs/_data/``.\n\nExploring Tenks \u0026 the Seed\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nVerify that Tenks has created ``controller0`` and ``compute0`` VMs:\n\n.. code-block:: console\n\n    sudo virsh list --all\n\nVerify that `virtualbmc \u003chttps://opendev.org/openstack/virtualbmc\u003e`_ is running:\n\n.. code-block:: console\n\n    ~/tenks-venv/bin/vbmc list\n    +-------------+---------+--------------+------+\n    | Domain name | Status  | Address      | Port |\n    +-------------+---------+--------------+------+\n    | compute0    | running | 192.168.33.4 | 6231 |\n    | controller0 | running | 192.168.33.4 | 6230 |\n    +-------------+---------+--------------+------+\n\nVirtualBMC config is here (on the VM hypervisor host):\n\n.. code-block:: console\n\n    /root/.vbmc/controller0/config\n\nNote that the controller and compute node are registered in Ironic, in the bifrost container.\nOnce kayobe is deployed and configured the compute0 and controller0 will be controlled by\nbifrost and not virsh commands.\n\n.. code-block:: console\n\n    ssh stack@192.168.33.5\n    docker exec -it bifrost_deploy bash\n    export OS_CLOUD=bifrost\n    baremetal node list\n    +--------------------------------------+-------------+---------------+-------------+--------------------+-------------+\n    | UUID                                 | Name        | Instance UUID | Power State | Provisioning State | Maintenance |\n    +--------------------------------------+-------------+---------------+-------------+--------------------+-------------+\n    | d7184461-ac4b-4b9e-b9ed-329978fc0648 | compute0    | None          | power on    | active             | False       |\n    | 1a40de56-be8a-49e2-a903-b408f432ef23 | controller0 | None          | power on    | active             | False       |\n    +--------------------------------------+-------------+---------------+-------------+--------------------+-------------+\n    exit\n\nEnabling Centralised Logging\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nIn Kolla-Ansible, centralised logging is easily enabled and results in the\ndeployment of OpenSearch services and configuration to forward\nall OpenStack service logging. **Be cautious as OpenSearch will consume a\nsignificant portion of available resources on a standard deployment.**\n\nTo enable the service, one flag must be changed in\n``~/deployment/src/kayobe-config/etc/kayobe/kolla.yml``:\n\n.. code-block:: diff\n\n    -#kolla_enable_central_logging:\n    +kolla_enable_central_logging: yes\n\nThis will deploy ``opensearch`` and ``opensearch_dashboards`` containers, and\nconfigure logging via ``fluentd`` so that logging from all deployed Docker\ncontainers will be routed to OpenSearch.\n\nBefore this can be applied, it is necessary to download the missing images to\nthe seed VM. Pull, retag and push the centralised logging images:\n\n.. code-block:: console\n\n   ~/deployment/src/kayobe-config/pull-retag-push-images.sh ^opensearch\n\nTo deploy the logging stack:\n\n.. code-block:: console\n\n    kayobe overcloud container image pull\n    kayobe overcloud service deploy\n\nAs simple as that...\n\nThe new containers can be seen running on the controller node:\n\n.. code-block:: console\n\n    $ ssh stack@192.168.33.3 docker ps\n    CONTAINER ID   IMAGE                                                                        COMMAND                  CREATED       STATUS                 PORTS     NAMES\n    fad79f29afbc   192.168.33.5:4000/openstack.kolla/opensearch-dashboards:2025.1-rocky-9       \"dumb-init --single-…\"   6 hours ago   Up 6 hours (healthy)             opensearch_dashboards\n    64df77adc709   192.168.33.5:4000/openstack.kolla/opensearch:2025.1-rocky-9                  \"dumb-init --single-…\"   6 hours ago   Up 6 hours (healthy)             opensearch\n\nWe can see the log indexes in OpenSearch:\n\n.. code-block:: console\n\n   curl -X GET \"192.168.33.3:9200/_cat/indices?v\"\n\nTo access OpenSearch Dashboards, we must first forward connections from our\npublic interface to the OpenSearch Dashboards service running on our\n``controller0`` VM.\n\nThe easiest way to do this is to add OpenSearch Dashboards's default port (5601) to our\n``configure-local-networking.sh`` script in ``~/deployment/src/kayobe-config/``:\n\n.. code-block:: diff\n\n    --- a/configure-local-networking.sh\n    +++ b/configure-local-networking.sh\n    @@ -20,7 +20,7 @@ seed_hv_private_ip=$(ip a show dev $iface | grep 'inet ' | awk '{ print $2 }' |\n     # Forward the following ports to the controller.\n     # 80: Horizon\n     # 6080: VNC console\n    -forwarded_ports=\"80 6080\"\n    +forwarded_ports=\"80 6080 5601\"\n\nThen rerun the script to apply the change:\n\n.. code-block:: console\n\n    ~/deployment/src/kayobe-config/configure-local-networking.sh\n\nWe can now connect to OpenSearch Dashboards using our hypervisor host public IP and port 5601.\n\nThe username is ``opensearch`` and the password we can extract from the\nKolla-Ansible passwords (in production these would be vault-encrypted\nbut they are not here).\n\n.. code-block:: console\n\n   grep opensearch_dashboards ~/deployment/src/kayobe-config/etc/kolla/passwords.yml\n\nOnce you're in, OpenSearch Dashboards needs some further setup which is not automated.\nSet the log index to ``flog-*`` and you should be ready to go.\n\nAdding the Barbican service\n^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n`Barbican \u003chttps://docs.openstack.org/barbican/latest/\u003e`_ is the OpenStack\nsecret management service. It is an example of a simple service we\ncan use to illustrate the process of adding new services to our deployment.\n\nAs with the Logging service above, enable Barbican by modifying the flag in\n``~/deployment/src/kayobe-config/etc/kayobe/kolla.yml`` as follows:\n\n.. code-block:: diff\n\n    -#kolla_enable_barbican:\n    +kolla_enable_barbican: yes\n\nThis instructs Kolla to install the barbican api, worker \u0026 keystone-listener\ncontainers. Pull down barbican images:\n\n.. code-block:: console\n\n   ~/deployment/src/kayobe-config/pull-retag-push-images.sh barbican\n\nTo deploy the Barbican service:\n\n.. code-block:: console\n\n    # Activate the venv if not already active\n    source ~/deployment/env-vars.sh\n\n    kayobe overcloud container image pull\n    kayobe overcloud service deploy\n\nOnce Barbican has been deployed it can be tested using the barbicanclient\nplugin to the OpenStack CLI. This should be installed and tested in the\nOpenStack venv:\n\n.. code-block:: console\n\n    # Deactivate existing venv context if necessary\n    deactivate\n\n    # Activate the OpenStack venv\n    source ~/deployment/venvs/os-venv/bin/activate\n\n    # Install barbicanclient\n    pip install python-barbicanclient -c https://releases.openstack.org/constraints/upper/2025.1\n\n    # Source the OpenStack environment variables\n    source ~/deployment/src/kayobe-config/etc/kolla/public-openrc.sh\n\n    # Store a test secret\n    openstack secret store --name mysecret --payload foo=bar\n\n    # Copy the 'Secret href' URI for later use\n    SECRET_URL=$(openstack secret list --name mysecret -f value --column 'Secret href')\n\n    # Get secret metadata\n    openstack secret get ${SECRET_URL}\n\n    # Get secret payload\n    openstack secret get ${SECRET_URL} --payload\n\nCongratulations, you have successfully installed Barbican on Kayobe.\n\n\nReferences\n==========\n\n* Kayobe documentation: https://docs.openstack.org/kayobe/latest/\n* Source: https://github.com/stackhpc/a-universe-from-nothing\n* Bugs: https://github.com/stackhpc/a-universe-from-nothing/issues\n* IRC: #openstack-kolla\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fstackhpc%2Fa-universe-from-nothing","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fstackhpc%2Fa-universe-from-nothing","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fstackhpc%2Fa-universe-from-nothing/lists"}