Fresh installation fails when using amphora test image: expects queries on /1.0/info

[Pedro Guimarães]

Cloud: stein
Non-HA mode
Simple installation on top of MAAS with single network

Deployed Octavia and followed procedure on: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-octavia.html

Get amphora test-image:
wget http://tarballs.openstack.org/octavia/test-images/test-only-amphora-x64-haproxy-ubuntu-bionic.qcow2 --output-document images/amphora-x64-haproxy.qcow2

Octavia fails because installed packages reach for amphora version on mgmt network using API v0.5 (hence, path is: /0.5/info). However, more recent test image only accepts v1.0 (/1.0/info or initial discovery query on /).

I can see that HAProxy driver code on /usr/lib/python3/dist-packages/octavia/ does not contain references to API 1.0, such as:
https://github.com/openstack/octavia/blob/stable/stein/octavia/amphorae/drivers/haproxy/rest_api_driver.py#L57

Only available work-around to make it work is:
export export DIB_REPOREF_amphora_agent=stable/rocky # Also tested with stein and still expects v1.0
# Pull diskimage-create script from octavia's source -> follow procedure to set it up
./diskimage-create.sh -r ubuntu -x

Same behavior when using Train as openstack-version.

[Alex Kavanagh (ajkavanagh)]

So, is this using the retrofix image that the charm-octavia toolset provides to create amphorae images? Does it work with the retrofix images?

[Steven Parker (sbparke)]

The latest octavia charm v#11 will not work with amphora image built from --branch stable/stein due to this issue. I built the amphora image from stable/stein and the API version referenced from the octavia charm installation is v0.5 but the version has changed for the amphora virtual machine to v1.0. This results in a failure to query the REST interface hosted by the amphora image from octavia.

WORK AROUND

# use the release tags for stein not the master branch for stein
# git rev-list -n 1 4.0.1
# note version 4.1.0 does not work

export DIB_REPOREF_amphora_agent=<Tag hash from above>
export DIB_REPOLOCATION_amphora_agent=https://opendev.org/openstack/octavia

Then you can build the amphora image

./diskimage-create/diskimage-create.sh -d bionic -t raw -s 3

octavia code ....
# API_VERSION = '0.5'
# ./octavia/common/constants.py

Thanks,

  Steven

[Steven Parker (sbparke)]

This issue is related to BUG:

https://bugs.launchpad.net/cloud-archive/+bug/1847243

The API seems to have been changed to address a security issue:

OSSA-2019-005 / CVE-2019-17134

Reverting the amphora image may not be advised.

Thanks,
  Steven

[Launchpad Janitor (janitor)]

[Expired for OpenStack Octavia Charm because there has been no activity for 60 days.]

[Pedro Guimarães (pguimaraes)]

@ajkavanagh
I am following the procedure described on: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-octavia.html
and I am seeing retrofit charm's action hanging.

More details on: https://pastebin.canonical.com/p/6n5YytkJBR/

strace shows /snap/octavia-diskimage-retrofit/104/bin/retrofit.sh is stuck on a wait.

[Frode Nordahl (fnordahl)]

Depending on whether you have KVM acceleration enabled, the speed of your computer and the bandwidth available on your internet connection, this process may take some time.

The process you would be interested in for a strace would be qemu.

You could always run the tool directly with debug enabled to get detailed output on its progress.

[Pedro Guimarães (pguimaraes)]

Hi Frode, thanks for the feedback. I could see what was happening on qemu instead with strace.
Eventually it synced the amphora image.