Bug 1904549

Summary: POST to /networks/create with docker compatible API results in panic
Product: Red Hat Enterprise Linux 8 Reporter: Jon McGuire <jonmcguire1>
Component: podmanAssignee: Jhon Honce <jhonce>
Status: CLOSED ERRATA QA Contact: Edward Shen <weshen>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 8.3CC: bbaude, dwalsh, jligon, jnovy, joarcher, lsm5, mheon, pthomas, tsweeney, umohnani, weshen, ypu
Target Milestone: rc   
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: podman-3.0 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-05-18 15:32:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
network-create-panic-stack-trace none

Description Jon McGuire 2020-12-04 18:03:12 UTC
Created attachment 1736495 [details]
network-create-panic-stack-trace

Context:
Testing for IBM Edge Application Manager compatibility with podman using docker compatible API's (podman-docker) on RHEL 8.3.

Description of problem:
When creating the networks for our containers we POST to /networks/create expecting the network to be created but results in a panic.

Error:
WARN[0074] Recovering from API handler panic: runtime error: index out of range [0] with length 0


Version-Release number of selected component (if applicable):
podman version
Version:      2.2.0
API Version:  2.1.0
Go Version:   go1.13.15
Built:        Tue Dec  1 10:40:49 2020
OS/Arch:      linux/amd64

A newer version is required for testing our product due to encountering bug 1884668 which was fixed.

How reproducible:
100% - multiple attempts to reproduce using our product and it was constantly reproducible with 0% chance of success.

Steps to Reproduce:
1. Setup dependencies, 8.3, podman-docker, podman 2.2
2. POST /networks/create using the docker compatible API rather than podman native API

Note: This was specifically encountered through the test of our product on podman, I have not tested yet a direct post through API to create a network outside of this product but could help isolate.

Actual results:
When creating the networks for our containers we POST to /networks/create expecting the network to be created but results in a panic.

Expected results:
For the network to be created with the appropriate POST input.

Additional info:

I attempted to gather the request body input (if needed) however was unable to capture via IEAM (security) or podman. If this is needed and we have a way to gather this information from the podman API please let me know and I will gather this during another test run.

Comment 1 Brent Baude 2020-12-04 18:45:08 UTC
can you provide a reproducer via curl and give that here?

Comment 2 Brent Baude 2020-12-04 18:49:40 UTC
or slap socat between the sockets to capture it

Comment 3 Jon McGuire 2020-12-08 18:53:39 UTC
What I've done for now is captured a reproducer using socat from a docker installation so we have an example input (couldn't find a quick or easy way to do it via podman without varlink). This gives us the same information needed at least in terms of REST request input. If you need me to additionally capture the output of a reproducer to the podman API specifically using a manual CURL I can do that as well, just let me know.


REQUEST DATA:

> 2020/12/08 10:37:24.850498  length=652 from=0 to=651
POST /networks/create HTTP/1.1\r
Host: unix.sock\r
User-Agent: go-dockerclient\r
Content-Length: 477\r
Content-Type: application/json\r
Accept-Encoding: gzip\r
Connection: close\r
\r
{"Name":"ed050a752c0a4d1fbab5695cc7b934b9f6c8b6c2ae5bb4c832bdfddd10ade275","Driver":"bridge","Scope":"","IPAM":{"Driver":"default","Config":[],"Options":null},"Options":{"com.docker.network.bridge.default_bridge":"false","com.docker.network.bridge.enable_icc":"true","com.docker.network.bridge.enable_ip_masquerade":"true"},"Labels":{"openhorizon.anax.network":""},"CheckDuplicate":true,"Internal":false,"EnableIPv6":false,"Attachable":false,"ConfigOnly":false,"Ingress":false}< 2020/12/08 10:37:24.935959  length=314 from=0 to=313
HTTP/1.1 201 Created\r
Api-Version: 1.40\r
Content-Type: application/json\r
Docker-Experimental: false\r
Ostype: linux\r
Server: Docker/19.03.14 (linux)\r
Date: Tue, 08 Dec 2020 18:37:24 GMT\r
Content-Length: 87\r
Connection: close\r
\r
{"Id":"b7471d08bfaf9f8c25d2950db035682a1a592f554f0d21cbaeb8f40ff32330c8","Warning":""}

Comment 4 john archer 2021-01-15 16:38:48 UTC
Looking for an update here.  I'm currently working with the IEAM team at IBM and have tested the hzn client on a RHEL 8.3 client, however had to remove podman and install docker ce in order for IEAM to register the node.  According to IEAM folks this bug is a blocker to their pushing podman support through.

Comment 6 Daniel Walsh 2021-01-16 11:05:44 UTC
Fixed in podman 3.0

Comment 10 Jon McGuire 2021-01-21 16:01:40 UTC
Daniel, thanks for clarifying this is fixed in 3.0. Is there a release date for 3.0 established yet? We have an eGA date in March for IEAM and this is a direct dependency of successful Podman support in the product. If Podman 3.0 will not be GA'd by March can get this fix back-ported to a currently released, stable version of Podman that is GA'd or not a release candidate?

Comment 11 Daniel Walsh 2021-01-22 10:08:10 UTC
podman 3.0 is to be released in RHEL8.4 which I believe happens in May.  RHEL 8.3.1 is about to be released in February, which is podman 2.2.1 (I believe) and I am not sure if this has the fix.

There are no other releases planned.

Comment 15 errata-xmlrpc 2021-05-18 15:32:56 UTC
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 (Moderate: container-tools:rhel8 security, bug fix, and enhancement update), 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/RHSA-2021:1796

Comment 16 Red Hat Bugzilla 2023-09-15 00:52:34 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days