Search This Blog

Showing posts with label tripleo. Show all posts
Showing posts with label tripleo. Show all posts

Monday, June 29, 2020

TripleO Container steps

Container steps

Similar to bare metal, containers are brought up in a stepwise manner. The current architecture supports bringing up baremetal services alongside containers. Therefore, baremetal steps may be required depending on the service and they are always executed before the corresponding container step.

The list below represents the correlation between the baremetal and the container steps. These steps are executed sequentially:

  • Containers config files generated per hiera settings.

  • Host Prep

  • Load Balancer configuration baremetal

    • Step 1 external steps (execute Ansible on Undercloud)

    • Step 1 deployment steps (Ansible)

    • Common Deployment steps

      • Step 1 baremetal (Puppet)

      • Step 1 containers

  • Core Services (Database/Rabbit/NTP/etc.)

    • Step 2 external steps (execute Ansible on Undercloud)

    • Step 2 deployment steps (Ansible)

    • Common Deployment steps

      • Step 2 baremetal (Puppet)

      • Step 2 containers

  • Early Openstack Service setup (Ringbuilder, etc.)

    • Step 3 external steps (execute Ansible on Undercloud)

    • Step 3 deployment steps (Ansible)

    • Common Deployment steps

      • Step 3 baremetal (Puppet)

      • Step 3 containers

  • General OpenStack Services

    • Step 4 external steps (execute Ansible on Undercloud)

    • Step 4 deployment steps (Ansible)

    • Common Deployment steps

      • Step 4 baremetal (Puppet)

      • Step 4 containers (Keystone initialization occurs here)

  • Service activation (Pacemaker)

    • Step 5 external steps (execute Ansible on Undercloud)

    • Step 5 deployment steps (Ansible)

    • Common Deployment steps

      • Step 5 baremetal (Puppet)

      • Step 5 containers

Sunday, June 28, 2020

View the list of images on the undercloud docker-distribution registry

To view the list of images on the undercloud docker-distribution registry use the following command:

(undercloud) $ curl http://192.168.24.1:8787/v2/_catalog | jq .repositories[]

To view a list of tags for a specific image, use the skopeo command:

(undercloud) $ curl -s http://192.168.24.1:8787/v2/rhosp13/openstack-keystone/tags/list | jq .tags

To verify a tagged image, use the skopeo command:

(undercloud) $ skopeo inspect --tls-verify=false docker://192.168.24.1:8787/rhosp13/openstack-keystone:13.0-44

Saturday, June 27, 2020

Updating network configuration on the Overcloud after a deployment

By default, subsequent change(s) made to network configuration templates (bonding options, mtu, bond type, etc) are not applied on existing nodes when the overcloud stack is updated.

To push an updated network configuration add UPDATE to the list of actions set in the NetworkDeploymentActions parameter. (The default is ['CREATE'], to enable network configuration on stack update it must be changed to: ['CREATE','UPDATE'].)

  • Enable update of the network configuration for all roles by adding the following to parameter_defaults in an environment file:

    parameter_defaults:
    NetworkDeploymentActions: ['CREATE','UPDATE']
  • Limit the network configuration update to nodes of a specific role by using a role-specific parameter, i.e: {role.name}NetworkDeploymentActions. For example to update the network configuration on the nodes in the Compute role, add the following to parameter_defaults in an environment file:

    parameter_defaults:
    ComputeNetworkDeploymentActions: ['CREATE','UPDATE']