In addition to usual OSP upgrade steps, Octavia has possible specific enhancements for a better upgrade experience. A major identified item here is the amphora image rotation during upgrade.
This RFE depends on the completion of the RFE for RHEL8 support in Octavia (bug 1623857). Once bug 1623857 is all done, we can fully test amphora image rotation during an upgrade.
I checked Amphora rotation (topology=single) using an OSP15 deployment Puddle RHOS_TRUNK-15.0-RHEL-8-20190716.n.0, which passed phase 1. For QE: ==== You may use the following as a base reference for verification of this RFE, but please note that this is quite basic and does not cover possible corner cases and is probably not enough for full verification. Steps: ====== 1. Fetch the latest[1] available OSP14 Amphora image. 2. Extract the image from the RPM and uploaded it to glance $ rpm2cpio octavia-amphora-image-x86_64-14.0-20190624.1.el7ost.noarch.rpm | cpio -idmv ./usr/share/openstack-octavia-amphora-images/octavia-amphora-14.0-20190624.1-x86_64-rpm.manifest ./usr/share/openstack-octavia-amphora-images/octavia-amphora-14.0-20190624.1-x86_64-signature.manifest ./usr/share/openstack-octavia-amphora-images/octavia-amphora-14.0-20190624.1.x86_64-CHECKSUM.md5 ./usr/share/openstack-octavia-amphora-images/octavia-amphora-14.0-20190624.1.x86_64-CHECKSUM.sha256 ./usr/share/openstack-octavia-amphora-images/octavia-amphora-14.0-20190624.1.x86_64.qcow2 ./usr/share/openstack-octavia-amphora-images/version-14.0-20190624.1.el7ost.txt * Note: for the purpose of this test, we would only need the .qcow2 file. 3. Copy it over to the undercloud-0 node and upload to glance. Note that the currently loaded image is owned (owner field) by the 'service' project, which means that the image we are about to upload must be owned by the same project for Octavia to detect it. $ AMPHORA_TAG=amphora-image $ OSP15_AMP_ID=$(openstack image list --tag $AMPHORA_TAG -f value -c ID) $ OSP15_AMP_OWNER=$(openstack image show $OSP15_AMP_ID -f value -c owner) $ openstack image create octavia-amphora-14.0-20190624.1.x86_64 --container-format bare --disk-format qcow2 --file octavia-amphora-14.0-20190624.1.x86_64.qcow2 --tag $AMPHORA_TAG --project $OSP15_AMP_OWNER 4. Now that the OSP14 Amphora image (based on RHEL7) is loaded to glance and tagged with 'amphora-image', Octavia will use it since it has the most recent timestamp. Create a Load balancer $ NET_ID=$(openstack network create test-network1 -f value -c id) $ SUBNET_ID=$(openstack subnet create --subnet-range 192.168.99.0/24 --network $NET_ID test-subnet1 -f value -c id) $ openstack loadbalancer create --name test_loadbalancer1 --vip-subnet-id $SUBNET_ID 5. While Octavia build the loadbalancer, create a couple of nova instances to be used as pool members and plug them to a routable network $ ROUTER_ID=$(openstack router create test-router1 -f value -c id) $ openstack router add subnet $ROUTER_ID $SUBNET_ID $ KEY_NAME="test-key1" $ ssh-keygen -b 2048 -t rsa -f $KEY_NAME -N "" $ openstack keypair create --public-key=${KEY_NAME}.pub ${KEY_NAME} $ PROJECT_ID=$(openstack project show admin -f value -c id) $ DEFAULT_SEC_GROUP_ID=$(openstack security group list --project ${PROJECT_ID} | awk '/default/ {print $2}') $ list create --protocol tcp --dst-port 80:80 ${DEFAULT_SEC_GROUP_ID $ openstack security group rule create --protocol tcp --dst-port 22:22 ${DEFAULT_SEC_GROUP_ID} $ openstack security group rule create --protocol icmp ${DEFAULT_SEC_GROUP_ID} $ FLAVOR_ID=$(openstack flavor show m1.nano -c id -f value) $ MEMBERS_IMAGE_ID=$(openstack image show cirros-0.4.0-x86_64-disk.img -f value -c id) $ NOVA_BOOT_ARGS="--key-name ${KEY_NAME} --image ${MEMBERS_IMAGE_ID} --flavor ${FLAVOR_ID} --nic net-id=${NET_ID}" $ openstack server create ${NOVA_BOOT_ARGS} member1 $ openstack server create ${NOVA_BOOT_ARGS} member2 $ IP1=$(openstack server show member1 | awk '/test-network1/ {print $4}' | cut -d "=" -f 2) $ IP2=$(openstack server show member2 | awk '/test-network1/ {print $4}' | cut -d "=" -f 2) 6. Complete load balancer sub-resources creation $ openstack loadbalancer listener create test_loadbalancer1 --protocol HTTP --protocol-port 80 --name test_listener1 $ openstack loadbalancer pool create --lb-algorithm ROUND_ROBIN --listener test_listener1 --protocol HTTP --name test_pool1 $ openstack loadbalancer member create --subnet-id $SUBNET_ID --address $IP1 --protocol-port 80 test_pool1 $ openstack loadbalancer member create --subnet-id $SUBNET_ID --address $IP2 --protocol-port 80 test_pool1 7. Copy the private key to one of the controllers to copy a file to the cirros instances, using the qrouter network namespace. 8. via qrouter namespace, SCP the following script into the cirros instances and activate it. $ yum install -y $ wget https://raw.githubusercontent.com/openstack/octavia/master/devstack/samples/singlenode/webserver. $ ip netns exec <qrouter-ns-id> scp -i test-key1 -o StrictHostKeyChecking=no webserver.sh cirros@<IP_ADDRESS>:webserver.sh $ ip netns exec <qrouter-ns-id> ssh -o UserKnownHostsFile=/dev/null -i test-key -o StrictHostKeyChecking=no -q cirros@<IP_ADDRESS> "screen -d -m sh webserver.sh" * Note: if you want to use the default cirros password instead, the password should be: gocubsgo 9. Check load balancing works. # for i in {1..10}; do curl 192.168.99.89 ; done Welcome to 192.168.99.16 Welcome to 192.168.99.225 Welcome to 192.168.99.16 Welcome to 192.168.99.225 Welcome to 192.168.99.16 Welcome to 192.168.99.225 Welcome to 192.168.99.16 Welcome to 192.168.99.225 Welcome to 192.168.99.16 Welcome to 192.168.99.225 10. Delete the OSP14 Amphora image from Glance. $ openstack image delete octavia-amphora-14.0-20190624.1.x86_64 11. Failover the loadbalancer and wait for it to move back from PENDING_UPDATE to ACTIVE $ openstack loadbalancer failover test_loadbalancer1 12. Check that the Amphora instance is running with the OSP15 image. $ openstack server list --all 13. Check load balancing works. # for i in {1..10}; do curl 192.168.99.89 ; done Welcome to 192.168.99.16 Welcome to 192.168.99.225 Welcome to 192.168.99.16 Welcome to 192.168.99.225 Welcome to 192.168.99.16 Welcome to 192.168.99.225 Welcome to 192.168.99.16 Welcome to 192.168.99.225 Welcome to 192.168.99.16 Welcome to 192.168.99.225
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2019:2811