OpenStack Octavia Charm

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

Bug #1844931 reported by Pedro Guimarães
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack Octavia Charm
Expired
Undecided
Unassigned

Bug Description

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.

CVE References

Revision history for this message
Alex Kavanagh (ajkavanagh) wrote :

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

Changed in charm-octavia:
status: New → Incomplete
Revision history for this message
Steven Parker (sbparke) wrote :

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

Revision history for this message
Steven Parker (sbparke) wrote :

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in charm-octavia:
status: Incomplete → Expired
Revision history for this message
Pedro Guimarães (pguimaraes) wrote :

@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.

Revision history for this message
Frode Nordahl (fnordahl) wrote :

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.

Revision history for this message
Pedro Guimarães (pguimaraes) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.