Skip to content

nerdctl inspect response responds to DevContainers with null values #3310

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
chews93319 opened this issue Aug 14, 2024 · 1 comment
Closed
Labels
kind/unconfirmed-bug-claim Unconfirmed bug claim

Comments

@chews93319
Copy link
Contributor

chews93319 commented Aug 14, 2024

Description

When using VSCode DevContainers with finch to re-open a "workspace within a container" (after successfully opening "workspace within a container" once and exiting), the "DevContainers Log" reports the following error: TypeError: Cannot read properties of null (reading 'Ports').

After some investigation, we observed two scenarios with finch using nerdctl:

  1. When a container is launched without a published port, the response of nerdctl inspect --mode=dockercompat omits the Ports key-value pair from the NetworkSettings.
  2. When nerdctl inspect --mode=dockercompat inspects an "Exited" container, the NetworkSettings key contains a null value.

Compared to the Docker scenarios:

  1. When a container is launched without a published port, the response of docker inspect, the Ports key-value pair is present within NetworkSettings entity, but the value is an empty structure.
  2. When docker inspect inspects an "Exited" container, the NetworkSettings key contains a complete structure of expected keys, all with "zero-value" values.

This bug affects integration of VSCode DevContainers with finch because DevContainers expects the complete NetworkSettings structure with all "zero-value" members for both of the scenarios.

Steps to reproduce the issue

Scenario 1: Container without published ports returns NetworkSettings without Ports entity

  1. Using finch, launch a container with specified ports
    a. finch run -p 8080:80 -d alpine:latest sleep infinity, which invokes nerdctl run -p 8080:80 -d alpine:latest sleep infinity
  2. Inspect the container to verify response payload
    a. finch inspect --mode=dockercompat <container_id>, which invokes nerdctl inspect --mode=dockercompat <container_id>
  3. Confirm the presence of Ports entity within NetworkSettings struct
    "NetworkSettings": {
        "Ports": {
            "80/tcp": [
                {
                    "HostIp": "0.0.0.0",
                    "HostPort": "8080"
                }
            ]
        },
        "GlobalIPv6Address": "",
        "GlobalIPv6PrefixLen": 0,
        "IPAddress": "10.4.0.9",
        "IPPrefixLen": 24,
        "MacAddress": "xx:xx:xx:xx:xx:xx",
        "Networks": {
            "unknown-eth0": {
                "IPAddress": "10.4.0.9",
                "IPPrefixLen": 24,
                "GlobalIPv6Address": "",
                "GlobalIPv6PrefixLen": 0,
                "MacAddress": "xx:xx:xx:xx:xx:xx"
            }
        }
    }
    
  4. Create another container without a published port
    a. finch run -d alpine:latest sleep infinity, which invokes nerdctl run -d alpine:latest sleep infinity
  5. Inspect the new container to verify response payload
    a. finch inspect --mode=dockercompat <container_id>, which invokes nerdctl inspect --mode=dockercompat <container_id>
  6. Confirm the lack of presence of Ports entity within NetworkSettings struct
    "NetworkSettings": {
        "GlobalIPv6Address": "",
        "GlobalIPv6PrefixLen": 0,
        "IPAddress": "10.4.0.10",
        "IPPrefixLen": 24,
        "MacAddress": "xx:xx:xx:xx:xx:xx",
        "Networks": {
            "unknown-eth0": {
                "IPAddress": "10.4.0.10",
                "IPPrefixLen": 24,
                "GlobalIPv6Address": "",
                "GlobalIPv6PrefixLen": 0,
                "MacAddress": "xx:xx:xx:xx:xx:xx"
            }
        }
    }
    

Inspecting an Exited Container

  1. Using finch, launch a container with specified ports
    a. finch run -p 8070:70 -d alpine:latest sleep infinity, which invokes nerdctl run -p 8070:70 -d alpine:latest sleep infinity
  2. Inspect the container to verify response payload
    a. finch inspect --mode=dockercompat <container_id>, which invokes nerdctl inspect --mode=dockercompat <container_id>
  3. Confirm the presence of Ports entity within NetworkSettings struct
  4. Stop the container
    a. finch container stop <container_id>, which invokes nerdctl container stop <container_id>
  5. Inspect the container to verify response payload
    a. finch inspect --mode=dockercompat <container_id>, which invokes nerdctl inspect --mode=dockercompat <container_id>
  6. Confirm the null value of NetworkSettings struct
    "NetworkSettings": null
    

Describe the results you received and expected

For the "container with published port", the NetworkSettings includes the expected Ports struct and all appropriate information. This is already successful and should be maintained during any changes.

The expected results should be as follows for the two scenarios:

  1. When a container is launched without a published port, the response of nerdctl inspect --mode=dockercompat should include the Ports key-value pair within the NetworkSettings with a value of { }.
  2. When nerdctl inspect --mode=dockercompat inspects an "Exited" container, the NetworkSettings key should map to a struct containing all keys mapping to "zero-value" values.

What version of nerdctl are you using?

Observed behavior with both:
- Local build from branch release/1.7
- Local build from branch main

Are you using a variant of nerdctl? (e.g., Rancher Desktop)

None

Host information

No response

@chews93319 chews93319 added the kind/unconfirmed-bug-claim Unconfirmed bug claim label Aug 14, 2024
@chews93319 chews93319 changed the title nerdctl inspect response does not include Ports: { } for containers without published ports nerdctl inspect response does not include Ports: {} for containers without published ports Aug 14, 2024
chews93319 added a commit to chews93319/nerdctl that referenced this issue Aug 14, 2024
Related to containerd#3310

New behavior will always initialize a PortMap for the inspect response.
If published ports are available, then values will be included in the
response.

Signed-off-by: Sam Chew <[email protected]>
chews93319 added a commit to chews93319/nerdctl that referenced this issue Aug 14, 2024
Related to containerd#3310

New behavior will always initialize a PortMap for the inspect response.
If published ports are available, then values will be included in the
response.

Signed-off-by: Sam Chew <[email protected]>
chews93319 added a commit to chews93319/nerdctl that referenced this issue Aug 14, 2024
Related to containerd#3310

New behavior will always initialize a PortMap for the inspect response.
If published ports are available, then values will be included in the
response.

Signed-off-by: Sam Chew <[email protected]>
@chews93319 chews93319 changed the title nerdctl inspect response does not include Ports: {} for containers without published ports nerdctl inspect response responds to DevContainers with null values Aug 15, 2024
chews93319 added a commit to chews93319/nerdctl that referenced this issue Aug 15, 2024
Related to containerd#3310

New behavior will always initialize a NetworkSettings entity within the inspect response.
If the target container does not exist, the NetworkSettings will be full
of "zero-value" members.
If the target container is active, but ports were not published, then
the Ports key of NetworkSettings will have an empty structure value.
If the target container is active and ports were published, then the
Ports key of NetworkSettings will have populated values.

Signed-off-by: Sam Chew <[email protected]>
chews93319 added a commit to chews93319/nerdctl that referenced this issue Aug 15, 2024
Related to containerd#3310

New behavior will always initialize a NetworkSettings entity within the inspect response.
If the target container does not exist, the NetworkSettings will be full
of "zero-value" members.
If the target container is active, but ports were not published, then
the Ports key of NetworkSettings will have an empty structure value.
If the target container is active and ports were published, then the
Ports key of NetworkSettings will have populated values.

Signed-off-by: Sam Chew <[email protected]>
chews93319 added a commit to chews93319/nerdctl that referenced this issue Aug 16, 2024
Related to
[containerd#3310](containerd#3310)

New behavior will always initialize a NetworkSettings entity
for the inspect response, including Ports child member.

If inspecting a running container with published ports,
then all information will be correctly returned.
If inspecting a running container without published ports,
then NetworkSettings will include an initialized Ports member.
If inspecting a stopped/exited container,
then an entirely initialized, "empty-value" NetworkSettings
is returned.

Signed-off-by: Sam Chew <[email protected]>
chews93319 added a commit to chews93319/nerdctl that referenced this issue Aug 16, 2024
Related to
[containerd#3310](containerd#3310)

New behavior will always initialize a NetworkSettings entity
for the inspect response, including Ports child member.

If inspecting a running container with published ports,
then all information will be correctly returned.
If inspecting a running container without published ports,
then NetworkSettings will include an initialized Ports member.
If inspecting a stopped/exited container,
then an entirely initialized, "empty-value" NetworkSettings
is returned.

Signed-off-by: Sam Chew <[email protected]>
Shubhranshu153 pushed a commit to Shubhranshu153/nerdctl that referenced this issue Sep 8, 2024
Related to
[containerd#3310](containerd#3310)

New behavior will always initialize a NetworkSettings entity
for the inspect response, including Ports child member.

If inspecting a running container with published ports,
then all information will be correctly returned.
If inspecting a running container without published ports,
then NetworkSettings will include an initialized Ports member.
If inspecting a stopped/exited container,
then an entirely initialized, "empty-value" NetworkSettings
is returned.

Signed-off-by: Sam Chew <[email protected]>
Shubhranshu153 pushed a commit to Shubhranshu153/nerdctl that referenced this issue Sep 8, 2024
Related to
[containerd#3310](containerd#3310)

New behavior will always initialize a NetworkSettings entity
for the inspect response, including Ports child member.

If inspecting a running container with published ports,
then all information will be correctly returned.
If inspecting a running container without published ports,
then NetworkSettings will include an initialized Ports member.
If inspecting a stopped/exited container,
then an entirely initialized, "empty-value" NetworkSettings
is returned.

Signed-off-by: Sam Chew <[email protected]>
Shubhranshu153 pushed a commit to Shubhranshu153/nerdctl that referenced this issue Sep 8, 2024
Related to
[containerd#3310](containerd#3310)

New behavior will always initialize a NetworkSettings entity
for the inspect response, including Ports child member.

If inspecting a running container with published ports,
then all information will be correctly returned.
If inspecting a running container without published ports,
then NetworkSettings will include an initialized Ports member.
If inspecting a stopped/exited container,
then an entirely initialized, "empty-value" NetworkSettings
is returned.

Signed-off-by: Sam Chew <[email protected]>
@apostasie
Copy link
Contributor

That was fixed by #3318 right?
@AkihiroSuda close?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/unconfirmed-bug-claim Unconfirmed bug claim
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants