Skip to main content

Deploying and upgrading TripleO with local mirrors

Continued from

In the previous blogpost, I explained how to automate the RHEL mirror creation using Now we are going to learn how to deploy and upgrade TripleO using those.

Deploying TripleO


To use local mirrors in the undercloud, you simply need to get the generated osp<version>.repo that you generated with the rhel-local-mirrors playbook, and copy it to /etc/yum.repos.d/ , in the undercloud host:
sudo curl http://<local_mirror_ip>/osp<version>_repo/osp<version>.repo \
-o /etc/yum.repos.d/osp.repo
Then proceed with the standard instructions for deploy.


Each node from the overcloud (controllers, computes, etc...) needs to have a copy of the repository file from our server where we host the local mirrors. To achieve it, you can include an script that downloads the osp<version>.repo file when deploying.
This can be achieved with Heat templates:
heat_template_version: 2014-10-16
description: >
  File for downloading the repository file from the asset server
    type: OS::Heat::MultipartMime
      - config: {get_resource: assetrepo_config}
    type: OS::Heat::SoftwareConfig
      config: |
        sudo curl http://<local_mirror_ip>/osp<version>_repo/osp<version>.repo -o /etc/yum.repos.d/osp<version>.repo
    value: {get_resource: userdata}

And then creating the environment file that will reference it:
  OS::TripleO::NodeUserData: /home/stack/templates/asset-repo.yaml

Then you need to include that environment file in your deploy command:
openstack overcloud deploy --templates  -e ~/templates/asset-environment.yaml \

Upgrading TripleO


To upgrade the undercloud, you need to be sure to disable packages from previous versions, and enable the ones from the new version.
If using local mirrors you may need to remove  the older repo file:
sudo rm /etc/yum.repos.d/osp.repo
And create the new:
sudo curl http://<local_mirror_ip>/osp<version+1>_repo/osp<version+1>.repo -o /etc/yum.repos.d/osp.repo

After that, execute the yum update and openstack undercloud upgrade commands as usual.


To upgrade the overcloud, you need to disable the older repositories and enable the new ones at upgrade time. This is achieved by a parameter that is called UpgradeInitCommand. This needs to contain a custom bash script, that will disable the older repos and enable the new ones, based on your needs.
A sample environment using UpgradeInitCommand can be:
cat > overcloud-repos.yaml <<EOF
  UpgradeInitCommand: |
    set -e
    sudo rm /etc/yum.repos.d/osp.repo
    sudo curl http://<local_mirror_ip>/osp<version+1>_repo/osp<version+1>.repo -o /etc/yum.repos.d/osp.repo 

And then execute your upgrade command including that overcloud-repos.yaml file:
openstack overcloud deploy --templates \
    -e <full environment> \
    -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-composable-steps.yaml \
    -e overcloud-repos.yaml


Popular posts from this blog

Describing TOAD - TripleO automated deployer

An overview of the TOAD framework and the advantagesWhat is TOAD? Fully automated deployment using Ansible (single command spin up)Main goal: to automate OSP deployments for continuous integration (CI) and development purposesTOAD is a CI framework using off-the-shelf components that many partners are familiar with:JenkinsJenkins Job Builder (JJB): Quickstart (oooq): ELK Stack (ElasticSearch, Logstash, Kibana) Its core component is TripleO Quickstart, used for TripleO upstream testingFully customizable with oooq settings; can be extendedDeploy environments with one click; trash after finished Of course it’s open source! :) What components make up TOAD?Requirements to install TOADTwo different use cases: virtualized and baremetalOnly one Jenkins+Nginx VM needed t…

Start using whole disk images with TripleO

What are the differences between flat partition image and whole disk image? In order to understand this article, you first need to know what a flat partition image and a whole disk image are, and the differences between each other.
flat partition image: disk image that just contains all the desired content in a filesystem, but does not carry any information about partitions on it, and it does not include a bootloader. In order to boot from a whole disk image, the kernel and ramdisk images need to be passed independently when booting, relying on an external system to mount.whole disk image: image that contains all the information about partitions, bootloaders... as well as all the desired content. It can boot independently, without the need of external kernels or systems to mount it. Right now, OpenStack Ironic  supports both kind of images, but OpenStack TripleO was only supporting flat partition images.

TripleO added support for whole disk images Since python-tripleoclient 5.6.0 ver…

Automated OSP deployments with Tripleo Quickstart

In this article I'm going to show a method for automating OSP (RedHat OpenStack platform) deployments. These automated deployments can be very useful for CI, or simply to experiment and test with the system.
Components involvedTOAD: set of playbooks to deploy Jenkins, jenkins-job-builder and an optional ELK stack. This will install a ready to use system with all the preconfigured jobs (including OSP10 deployments and image building).TOAD jenkins-jobs: A set of job templates and macros, using jenkins-job-builder syntax, that get converted into Jenkins jobs for building the OSP base images and for deploying the system.TOAD job-configs: A set of job configurations to be used along with the jenkins-jobs repo. It provides a set of basic configs to build OpenStack using RDO or OSP.TripleO quickstart: set of ansible playbooks, used for building images and for RDO/OSP deployments. System requirementsOne VM to run a Jenkins master + nginx provided by TOAD. If you want to deploy additiona…